OAuth 2.0 is an industry-standard protocol for authorization. oAuth 2.0 focus on client developer simplicity while providing specific flows for web applications, mobile devices, and desktop application.
OpenIAM 4.2.0.x supports the following authorization grants.
|Authorization Code||The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token. After the user returns to the client via the redirect URL, the application will get the authorization code from the URL and use it to request an access token. Enterprise customers (4.2.1+) should use PKCE instead|
|Client credentials||The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. This is typically used by clients to access resources about themselves rather than to access a user's resources.|
|Health Level Seven Internation||SMART App Launch Framework used in healthcare. OAuth 2.0 authorization servers are configured to mediate access based on a set of rules configured to enforce institutional policy, which may include requesting end-user authorization. Additional details be found at: http://www.hl7.org/fhir/smart-app-launch/|
Note: OpenIAM 4.2.1.x (Enterprise edition) supports a more extensive list of authorization grant flows
The oAuth spec allows for significant flexibility in how applications can be integrated. The example below show to integrate a custom Springboot Application which uses the Authorization Grant Flow: Authorization Code.
Leverage the steps described below integrate your oAuth application with OpenIAM.
Create an Authentication Provider
To create a new Authentication provider:
- Login to the Webconsole and go to Access Control > Authentication Provider
- Go to
Create New Provider
oAuth Clientfrom the "Select a Provider Type" drop down as shown below
Configure oAuth Client Provider in OpenIAM
|Provider name||This can be any descriptive name to identify this configuration such as |
|Redirect URL||Redirect URLs are a critical part of the OAuth flow. After a user successfully authorizes an application, the authorization server will redirect the user back to the application with either an authorization code or access token in the URL. Since the redirect URL can contain sensitive information, it is critical that the service doesn’t redirect the user to an arbitrary location.|
|Allow multiple Active Tokens||Set this value to |
|Signing Algorithm||Select the algorithm used to sign tokens issued for your application or API. Example is |
|JWT Issuer||This is the JWT Issuer. It identitifies the client that will be issued the JWT token. In this case, we can put any descriptive value like |
|Final JWT Issuer view||This value will be automatically generated upon completing the "JWT Issue" value.|
|OpenID Connect Discovery URL||This value will be automatically generated upon completing the "JWT Issue" value. You can configure your OIDC application using the information found at the URL.|
|Authorization Grant Flow||The grant flow drop down requires the selection of a Grant type. The grant descirts how the client application to acquire an access token which can be used to authenticate a request to an API endpoint. Note: the grant type that you select here, must align with the grant flow that you define in your application. For this example, select |
|Client Authentication Type||Describes how credentials are passed to the authorization server. You can select between |
|Default Scopes||Scopes in OAuth 2.0 provide a way to limit the amount of access that is granted to an access token. You can select the scopes from the dropdown. Note that Scopes in OpenIAM are resources and you can manage them through the Resource Manager interface described under Access control.|
|Skip scope approval||Set this to |
|Token expiration||Access token expires after the specified minutes of being idle. You can set this value to |
|Use refresh token||Refresh tokens carry the information necessary to get a new access token. Whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server. In most cases, this value should be set to |
|Protect by 2FA||Set this value to |
The example represents a value Authentication provider configuration for use with the test Springboot application that was referenced earlier in this section..
Upon saving the configuration, the system will generate the
clientsecret which will be used by your oAuth Client.
Grant access to your application
To be able to access the service provider through the IdP, we must grant access to the service provider by associating it to an entitlement object such as a group / role. While this topic is described in detail in the access control section, the section below provides a brief reference to entitle an application through a role.
- Go to the Webconsole -> Access Control -> Role
- Find an existing role which you want to update such that it is entitled to your service provider
- View the role details by click on the icon in the Actions column
- Go to the
Role Entitlementsoption from the side menu as shown below
- Right click on
Resourcefollowed by select
Addas shown below
- From the
Resource typedrop down select
- From the adjacent dropdown, select the name of your authentication provider as shown below
The role has now been entitled.