This article describes the principles of OAuth 2.0 and how to configure OAuth 2.0 in Hybrid Access Gateway. The purpose of OAuth 2.0 is to give applications limited and secure access to an HTTP resource on behalf of an end-user without exposing that user’s credentials to the application or the user’s device.
This article describes the principles of OAuth 2.0 and how to configure OAuth 2.0 in Hybrid Access Gateway.
The purpose of OAuth 2.0 is to give applications limited and secure access to an HTTP resource on behalf of an end-user without exposing that user’s credentials to the application or the user’s device. OAuth 2.0 offers a way to limit what a specific client can access through “scopes”.
The most common scenario in OAuth 2.0 is accessing a protected resource on the resource server by providing an access token. There are multiple ways to provide the token, and the preferred way is to include it in the authorization header of the request. The resource server validates the token and lets the client through if the token is valid for the resource being requested.
OAuth 2.0 requires a database in order to store codes and tokens. The Hybrid Access Gateway appliance bundles a preconfigured PostgreSQL database with a predefined “oauth” user. It is also possible to configure an external database if needed. This is mandatory for systems running in distributed mode since the different nodes are sharing the OAuth 2.0 database configuration.
These are terms that are used in this article.
A grant type is a way to obtain an access token.
After registering a client and assigning it at least one scope, you add an access rule of the type “OAuth2 Bearer Token” to a web resource in order to protect it with OAuth 2.0. See Add access rule for more information.
If you revoke an access token, only that specific token is revoked. If you revoke a refresh token, all tokens related to that token are revoked.
If you have more than one description for a scope, only the first one will be used if the default consent template is configured.
If you wish to enable branding/localization, modify wwwroot/wa/scripts/oauth2consent.js. In this file, there are descriptions of which lines you need to uncomment to enable branding/localization. When the lines are uncommented, all that is needed is to pass the correct description key to the sendRequest function. One way of doing this is having different wwwroots for different brandings/localizations and passing different keys depending on the branding/localization.