Authorization Code Grant
Oauth 2.0 in Financial Services
As the name itself suggests this is the version 2.0 of popular authentication protocol Oauth.
In this blog I would like to discuss about the protocol, different flavors of Oauth2.0 and its applications in Financial Services. also would like to touch upon the popular frameworks for implementing this in JAVA.
What is Oauth 2.0 ?
The Technical definition published on IETF portal is as follows
bother to register, so stackoverflow offers you an option to login with Google or Facebook.
You can select either and it opens a login page of the respective application asks you to
key in your username and password and 'Voila' you are on your StackOverflow Home page.
So basis above example let me try mapping the highlighted entities of the IETF definition
with entities in the example
Third Party Application (Client) - StackOverFlow
HTTP Service (Resource/Authorization Server) - Google/Facebook (In our case this is also the Resource Server)
Resource Owner - It's You
So what exactly happens behind the scenes
Step 1 - StackOverflow redirects user to Login page of Facebook/Google and also adds certain
parameters in the login request like client_id, redirect_uri, scope, response_type, state.
As the name itself suggests this is the version 2.0 of popular authentication protocol Oauth.
In this blog I would like to discuss about the protocol, different flavors of Oauth2.0 and its applications in Financial Services. also would like to touch upon the popular frameworks for implementing this in JAVA.
What is Oauth 2.0 ?
The Technical definition published on IETF portal is as follows
"The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."
There are 4 popular ways of using Oauth2.0
1. Authorization Code
2. Implicit
3. Password
4. Client Credentials
5. Device Code
6. Refresh Token
1. Authorization Code
2. Implicit
3. Password
4. Client Credentials
5. Device Code
6. Refresh Token
Lets try to understand it with the real world scenario. Take an example of a popular
discussion forum like "StackOverFlow" you wish to participate in a discussion but don'tbother to register, so stackoverflow offers you an option to login with Google or Facebook.
You can select either and it opens a login page of the respective application asks you to
key in your username and password and 'Voila' you are on your StackOverflow Home page.
So basis above example let me try mapping the highlighted entities of the IETF definition
with entities in the example
Third Party Application (Client) - StackOverFlow
HTTP Service (Resource/Authorization Server) - Google/Facebook (In our case this is also the Resource Server)
Resource Owner - It's You
So what exactly happens behind the scenes
Step 1 - StackOverflow redirects user to Login page of Facebook/Google and also adds certain
parameters in the login request like client_id, redirect_uri, scope, response_type, state.
Eg: URL for user permission as follows,
https://www.google.com/auth
response_type=code - This tells the authorization server i.e. Google that the application i.e. StackOverflow is initiating the authorization code flow.
client_id - The public identifier for the application, obtained when the developer first registered the application. StacOverFlow's Client_Id.
redirect_uri - Tells the authorization server where to send the user back to after they approve the request.
scope - One or more space-separated strings indicating which permissions the application is requesting. The specific OAuth API you’re using will define the scopes that it supports.
state - The application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks.
When the user visits this URL, the authorization server (Google/Facebook) will present them with a prompt asking if they would like to authorize this application’s (StackOverflow) request.
Step 2 -
If the user approves the request, the authorization server will redirect the browser back to the redirect_uri specified by the application, adding a code and state to the query string.
For example, the user will be redirected back to a URL such as
https://stackoverflow.com/redirect
?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
&state=xcoiv98y2kd22vusuye3kch
The state value will be the same value that the application initially set in the request. The application is expected to check that the state in the redirect matches the state it originally set. This protects against CSRF and other related attacks.
The code is the authorization code generated by the authorization server. This code is relatively short-lived, typically lasting between 1 to 10 minutes depending on the OAuth service.
Step 3 -
We’re about ready to wrap up the flow. Now that the application has the authorization code, it can use that to get an access token.
The application makes a POST request to the service’s token endpoint with the following parameters:
grant_type=authorization_code - This tells the token endpoint that the application is using the Authorization Code grant type.
code - The application includes the authorization code it was given in the redirect.
redirect_uri - The same redirect URI that was used when requesting the code. Some APIs don’t require this parameter, so you’ll need to double check the documentation of the particular API you’re accessing.
client_id - The application’s client ID.
client_secret - The application’s client secret. This ensures that the request to get the access token is made only from the application, and not from a potential attacker that may have intercepted the authorization code.
The token endpoint will verify all the parameters in the request, ensuring the code hasn’t expired and that the client ID and secret match. If everything checks out, it will generate an access token and return it in the response!
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create delete"
}
The Authorization Code flow is complete! The application now has an access token it can use when making API requests.
Frameworks to implement Oauth2.0
1. Spring Security - It is Out-of-The-Box framework and provides most of the boiler plate implementation in its Framework Beans.
2. Apache Oltu - This is Apache's custom framework for implementing various Outh2.0 protocols. These are easy to customize but requires developers to write significant bit of code and take important design decisions.
Credits - https://developer.okta.com/ helped me understand these algorithms better
https://tools.ietf.org/html/rfc6749 - Oauth standards
https://www.google.com/auth
?response_type=code
&client_id=29352915982374239857
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=create+delete
&state=xcoiv98y2kd22vusuye3kch
&client_id=29352915982374239857
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=create+delete
&state=xcoiv98y2kd22vusuye3kch
response_type=code - This tells the authorization server i.e. Google that the application i.e. StackOverflow is initiating the authorization code flow.
client_id - The public identifier for the application, obtained when the developer first registered the application. StacOverFlow's Client_Id.
redirect_uri - Tells the authorization server where to send the user back to after they approve the request.
scope - One or more space-separated strings indicating which permissions the application is requesting. The specific OAuth API you’re using will define the scopes that it supports.
state - The application generates a random string and includes it in the request. It should then check that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks.
When the user visits this URL, the authorization server (Google/Facebook) will present them with a prompt asking if they would like to authorize this application’s (StackOverflow) request.
Step 2 -
If the user approves the request, the authorization server will redirect the browser back to the redirect_uri specified by the application, adding a code and state to the query string.
For example, the user will be redirected back to a URL such as
https://stackoverflow.com/redirect
?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
&state=xcoiv98y2kd22vusuye3kch
The state value will be the same value that the application initially set in the request. The application is expected to check that the state in the redirect matches the state it originally set. This protects against CSRF and other related attacks.
The code is the authorization code generated by the authorization server. This code is relatively short-lived, typically lasting between 1 to 10 minutes depending on the OAuth service.
Step 3 -
We’re about ready to wrap up the flow. Now that the application has the authorization code, it can use that to get an access token.
The application makes a POST request to the service’s token endpoint with the following parameters:
grant_type=authorization_code - This tells the token endpoint that the application is using the Authorization Code grant type.
code - The application includes the authorization code it was given in the redirect.
redirect_uri - The same redirect URI that was used when requesting the code. Some APIs don’t require this parameter, so you’ll need to double check the documentation of the particular API you’re accessing.
client_id - The application’s client ID.
client_secret - The application’s client secret. This ensures that the request to get the access token is made only from the application, and not from a potential attacker that may have intercepted the authorization code.
The token endpoint will verify all the parameters in the request, ensuring the code hasn’t expired and that the client ID and secret match. If everything checks out, it will generate an access token and return it in the response!
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create delete"
}
The Authorization Code flow is complete! The application now has an access token it can use when making API requests.
Frameworks to implement Oauth2.0
1. Spring Security - It is Out-of-The-Box framework and provides most of the boiler plate implementation in its Framework Beans.
2. Apache Oltu - This is Apache's custom framework for implementing various Outh2.0 protocols. These are easy to customize but requires developers to write significant bit of code and take important design decisions.
Credits - https://developer.okta.com/ helped me understand these algorithms better
https://tools.ietf.org/html/rfc6749 - Oauth standards
Comments
Post a Comment