OAuth 2 has become a popular protocol to follow for authorizing users to access protected resources. A typical OAuth 2 scenario:
A user requests access to a protected resource managed by a resource server via a User Agent, typically the user’s browser.
The resource server redirects the user via an HTTP redirect to an Authorization Endpoint managed by an Authorization Server that has an account for that user. The location of the redirect response has a field typically called redirect_uri.
The authorization server prompts the user for credentials to verify the user’s identity. It might also confirm that the user is OK with allowing the user agent access to the resource held at the resource server.
The user enters credentials and confirms allowing access if required.
The authorization server verifies user credentials and sends an authorization_code value at the redirect_uri.
A service running at the redirect_uri sends POST request to a Token Endpoint managed by the authorization server with authorization_code.
Token endpoint validates the authorization_code, generates an access_token, and sends it back to redirect_uri in response.
Service at redirect_uri retries the initial HTTP request adding access_token as a query string parameter.
The resource server validates access-token and allows access to the protected resource.
Problem
Often in a single page application (SPA), we see that the UX layer is responsible for both the GET call to the authorization code endpoint as well as the POST call to the access token endpoint to exchange the authorization code with the access token. The SPA then uses this token to make back end, typically REST calls to the resource server.
< ..
Support the originator by clicking the read the rest link below.
