A phone with a security lock resting on top of it. A server has a key resting on top of it that is placed beside the phone. There is a shield with a green checkmark on the other side of the phone.

In my recent engagement, I was tasked to set-up an access token request flow for a client application, which would enable the user access certain data without the need to re-enter the login credentials. This uses the functionality of OAuth 2.0 framework which utilizes an “Access Token” and the “Scope” parameter in determining what type of information can be accessed by the user without logging in.

The OAuth 2.0 framework has 2 types of Authorization Grants: Authorization Code and Implicit Grant.

In an Authorization Code flow, an Authorization Code is generated from an authorization server by calling the ISAM Advanced Access Control (AAC) authorization endpoint. The generated Authorization Code is then used by the 3rd Party application, who then calls the ISAM AAC token endpoint to generate the Access Token. That access token can then be used to establish a session on behalf of the user without the 3rd party application needing the user credentials. This method of token generation is more secure since it sends the access token directly to the client without exposing it to others through the user-agent.

In an Implicit Grant flow, the Access Token is directly generated by the authorization server after a user session is established. This flow is specifically used for clients with in-browser applications as it minimizes the number of calls needed to obtain an access token. Using Implicit grants provides faster response times, however security is a concern since the access token is sent in the URI fragment which can be exposed to unauthorized parties and risk being misused for client impersonation. The use of this specification should have some level of security control which can be provided by ISAM AAC.

These OAuth 2.0 specifications have their pros and cons depending on the use case. Based on my experience with them, the Authorization Code flow is more suitable if you have a 3rd party resource that needs to access certain information on behalf of the user without the user needing to login to that application. It will not work if the client application and 3rd party resource are one and the same since the ISAM session overrides the client ID used in the access token request. The Implicit Grant flow is more suitable for in-browser client applications since there is no 3rd party application involved and requires an ISAM session to be able to generate the access token.

OAuth 2.0 Authorization Code vs. Implicit Grant

Services

Solutions

Pricing

Resources

Events

About Us

Get Started