Token Handler application plugin helps with implementing the Token Handler pattern for Single Page Applications (SPAs). Learn more about the Token Handler pattern from our resource library articles.
Token Handler applications act as OAuth Agents as defined in the Token Handler pattern. Token Handler applications are configured in an application service profile, more specifically on the applications list. The following two figures illustrate listing and adding a Token Handler application.
Fig. 41 Listing all applications.
Fig. 42 Adding a Token Handler application.
After a Token Handler application is created, it needs to be configured in the edit application modal.
Fig. 43 Configure a Token Handler application.
The configuration is divided into two parts:
Typically, a single Token Handler application will handle one SPA, so it needs to be configured as such. The Single Page Application Base URL is the URL that the SPA will be running on. This setting is used to allow cross-origin resource sharing (CORS) requests from the SPA (all requests from the SPA to this token handler application will be cross-origin).
Single Page Application Base URL
The optional Backend for Frontend Parent Domain is only needed when the OAuth Agent and the OAuth Proxy will be running on different subdomains.
Backend for Frontend Parent Domain
Each token handler application needs to use an Authorization Server to authenticate and authorize users. The Use External OAuth Server switch button enables administrators to choose between two modes:
Use External OAuth Server
off
General
+ New Internal Client
Client Redirect URI
https://www.example.com/path
Fig. 44 Create a new internal client for token handler application.
on
SPAs may want to send extra parameters in authorization requests. The only parameter that is always allowed to be sent by SPAs is scope. Any other parameters (e.g. ui_locales or login_hint) have to be enabled using the Authorization Parameters Whitelist component. Any parameters listed in this component can be sent by SPAs in the login/start requests (described below).
scope
ui_locales
login_hint
Authorization Parameters Whitelist
login/start
Token handler applications will call the token endpoint on the configured authorization server. If a specific TLS trust is needed to connect to the server (e.g. the server is using self-signed certificates in pre-production environments) then an HTTP Client with a correctly configured client trust store has to be created and used (the trust store with the certificates the server is using).
To limit the exposure of cookies created by a token handler application, the path attribute is set on the relevant cookie with a value that matches the URL path to the token handler application that created the cookie (e.g. /<APP_ANONYMOUS_ENDPOINT>/<TOKEN_HANDLER_APP_ID>). This makes browsers send the cookie only to the token handler application (and not to a token handler proxy). In case there’s an HTTP reverse proxy in front of the Curity Identity Server and this proxy rewrites the path to the token handler application, the Curity Identity Server admin can override the value that is set in the path attribute of the cookie using the Session Cookie Path configuration setting.
/<APP_ANONYMOUS_ENDPOINT>/<TOKEN_HANDLER_APP_ID>
path
Session Cookie Path
It’s recommended to enable the Require Custom Header setting. It will make all the endpoints require a custom HTTP header: token-handler-version=1. When enabled, this header has to be sent in all token handler application requests. If not sent, the requests will be rejected. Requiring this header strengthens the security of token handler applications in cross-origin deployments by enforcing the browsers to send CORS pre-flight requests, thus enabling the token handler application to authorize a request prior to executing it. It prevents a sort of cross-site request forgery (CSRF) attacks based on CORS-safelisted requests. Starting from version 2.0 of each token handler proxy (e.g. Kong, Apigee, etc.), all proxies require this header as well. Refer to each token handler proxy documentation for details.
Require Custom Header
token-handler-version=1
2.0
For an Oauth Proxy, an elliptic-curve public key has to be configured. This key is taken from an asymmetric keypair where the public key is used here, by the Token Handler application to encrypt the cookie that will be sent to the OAuth Proxy, whereas the private key of the keypair is used on the Proxy side to decrypt the cookie.
A token handler application will expose an API that SPAs can call to actually use the Token Handler pattern. The API will be exposed on the application anonymous endpoint that was created in the same application profile as the Token Handler application. Each Token Handler application exposes five endpoints under these paths:
POST login/start
POST login/end
GET session
POST refresh
POST logout
These endpoints will be exposed under the path <BASE_URL>/<APP_ANONYMOUS_ENDPOINT>/<TOKEN_HANDLER_APP_ID>. Assume the Curity Identity Server’s base URL is set to https://example.com, the application profile’s anonymous endpoint is exposed with /apps-anonymous path and a Token Handler application with id token-handler1 is created. Then the API will be exposed under these paths:
<BASE_URL>/<APP_ANONYMOUS_ENDPOINT>/<TOKEN_HANDLER_APP_ID>
https://example.com
/apps-anonymous
token-handler1
https://example.com/app-anonymous/token-handler1/login/start
https://example.com/app-anonymous/token-handler1/login/end
https://example.com/app-anonymous/token-handler1/session
https://example.com/app-anonymous/token-handler1/refresh
https://example.com/app-anonymous/token-handler1/logout
To help SPA developers interact with OAuth Agents (token handler application plugins), Curity developed a lightweight JavaScript library. Refer to the library documentation for details on how to use it. The library will help SPA developers with calling the endpoints of token handler applications.
Starting from version 1.1.0, the library also includes the token-handler-version header in all requests to token handler applications (this header is enforced in a token handler application by enabling the Require Custom Header setting). SPAs are required to also send this header in all requests to a token handler proxy (starting from version 2.0 of all token handler proxies).
1.1.0
token-handler-version