The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints.
1. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
The OAuth2 implicit grant is a variant of other authorization grants. It allows a client to obtain an access token (and id_token, when using OpenId Connect) directly from the authorization endpoint, without contacting the token endpoint nor authenticating the client. This variant was designed for JavaScript based applications running in a Web browser: in the original OAuth2 specification, tokens are returned in a URI fragment. That makes the token bits available to the JavaScript code in the client, but it guarantees they won't be included in redirects toward the server. In OAuth2 implicit grant, the authorization endpoint issues access tokens directly to the client using a redirect URI that was previously supplied. It also has the advantage of eliminating any requirements for cross origin calls, which are necessary if the JavaScript application is required to contact the token endpoint.
An important characteristic of the OAuth2 implicit grant is the fact that such flows never return refresh tokens to the client.
Scenario:
I am developing a mobile application. The application will be using OAUTH2 implicit grant type to get Azure AD access tokens.
The application needs to be registered in Azure AD.
how to register the application in AzureAD ?
using the redirect URI
No comments:
Post a Comment