This page is for Authlete 3.0. For 2.x, see this page.
Introduction
This document is a tutorial to describe basic usage of Authlete APIs in order to implement OpenID Connect (OIDC) identity provider (IdP) server that supports the authorization code flow. In completing the tutorial, you will- Make requests simulating the requests which come from the authorization server to Authlete
- Set the issuer identifier in the Authlete Management Console, include additional claims in the authorization request to the Authlete authorize endpoint, and confirm that both the issuer and additional claims are included in the ID Token by decoding it.
Authorization Code Flow Components
NoteIn this tutorial, OIDC identity provider and relying party are described as authorization server and client respectively for convenience.
curl command. You may of course use an alternate HTTP client of your choice (PowerShell, Postman, etc.), but you’ll need to know how to adapt the instructions for yourself in this instance.
To understand how each piece fits together in this OAuth flow, we’ve provided a list of fully qualified domain names (FQDN) for each component. The FQDNs for the authorization server and the client are invented only for reference, and would of course be substituted for real ones in a real implementation.
NoteAPI endpoints are cluster specific. If using a service in another cluster, you’d substitute in the cluster’s two character ISO code for the complete domain name for that API endpoint (e.g. br, eu, jp).
Environment setup
NoteSettings in this section are the same as described in Authlete API Tutorial - OAuth 2.0 Basics. If you’ve already completed that tutorial, you can skip this section.
You can use the following values to create your client, leaving all other fields as default:
Once your client is created, go to Client Settings > Endpoints > Global Settings. In the Redirect URIs section, click Add to enter and save the URI where the client will receive authorization responses.
The following example properties are generated or specified when you create a client. These are values required when making requests as part of the
code flow that you will complete. Use the values you noted down in the environment setup section.
Now, let’s try the OIDC authorization code flow using this environment.
Walk-through
We’ve provided the following sequence diagram to help you understand each of the steps involved in the code flow. You can identify where you are at in the walk-through using the numbers which correspond to specific steps in the diagram.Authorization request from the client to the authorization server
We’ll use the following values as example parameters for the request (as specified previously).
When the resource owner attempts to access a protected resource through the client (steps #1, #2) the client makes an OIDC authentication request (authorization request) to the authorization server via user agent (steps #3, #4).
The authorization server receives the above data here shown as the HTTP
GET query string from the user agent.
- Whether a client associated with the client ID
12898884596863has been registered to the authorization server. It must be an OIDC relying party because ofscope=openid. - Whether the value of the redirect URI
https://client.example.org/cb/example.commatches with one of URIs registered to the client - Whether values of other parameters such as
response_type,scopeare applicable for the client, i.e. permitted for the client to specify in its request
scope and response_type are openid and code respectively.
However, in the Authlete architecture the authorization server is simply a proxy for the actual authorization logic contained in the Authlete API which is surfaced at the /auth/authorization endpoint. Once received, the Authlete API does the evaluation process on the authorization server’s behalf.
You’ll now simulate the authorization server’s request to this API.
Execute the curl command as follows (message #5). Make sure to replace <Service ID>, <Service Access Token> and <Client ID> by your own values generated in the previous step.
resultMessage, action and ticket as seen above.
resultMessageprovides a human-readable result of the request processing (See also Interpreting Authlete’s result codes).openid=trueindicates the request is to be processed in accordance with the OIDC protocol.actionindicates what the authorization server should do next. (See also Action Handling)ticketis required for the authorization server to make a request to another API in the next step. (See also Two-Step API Calls)
User authentication and confirmation of sharing authentication result
Actual interaction between the resource owner and the authorization server is out of scope in this tutorial. In most cases, authorization server would authenticate user with some credentials (e.g. ID/password), determine roles and privileges for the user, and ask the user if he or she authorizes to share the authentication result with the client (steps #7, #8, #9).Issuing an authorization code
Let’s assume the authorization server reaches the following state after completion of the previous process:- The authorization server has authenticated the resource owner, and determined that an identifier for the resource owner, to be shared with Authlete as a value of
subjectparameter, istestuser01. - The authorization server has got consent from the resource owner.
/auth/authorization/issue in order to issue an authorization code. It specifies values of subject and ticket that were a part of the response from /auth/authorization API, as request parameters.
Execute the following curl command (message #10), making sure to replace <Service ID>, <Service Access Token> and <Ticket> by your own values generated in the previous step.
resultMessage, action and responseContent.
resultMessageprovides a human-readable result of the request processing. (See also Interpreting Authlete’s result codes)actionindicates what the authorization server should do next. The value in this response isLOCATION, which means the authorization server should make a redirection response back to the user agent. (See also Action Handling)responseContentis the content of the response from the authorization server. (See also Action Handling)
Failure to issue an authorization code
Alternatively, the authorization server may fail to receive authorization. In this instance, it won’t issue tokens to the client. In that situation the authorization server would notify the client that the authorization flow is terminated. Authlete’s/auth/authorization/fail API supports the termination process in terms of messages to be sent to the client, and transfer method for the response.
To summarize, under most circumstances, the authentication server sends a request to either /auth/authorization/issue or /auth/authorization/fail API depending on the result of user authentication and consent.
Token request
Here we assume that the user agent receives the redirection response form the authorization server. It would send the following request (new line for readability) to the client (step #13).code parameter, construct a token request using its value and send it to the authorization server as follows (new lines for readability). https://as.example.com/token is the token endpoint URI in this tutorial (step #14).
/auth/token API to evaluate the request and create the response.
Execute the following curl command (step #15), again making sure to replace <Service ID>, <Service Access Token>, <Client ID>, <Client Secret> and <Code> by your own values generated in the previous step.
resultMessage, action and responseContent.
resultMessageprovides human-readable result of the request processing. (See also Interpreting Authlete’s result codes)actionindicates what the authorization server should do next. The value in this response isOK, which means the authorization server should make a token response back to the client. (See also Action Handling)responseContentis supposed to be content of the response from the authorization server. (See also Action Handling)
Decoding ID token
The most common next step is for the client to decode the value ofid_token in the response and verify it.
To perform this function, we’re going to decode the token with the free open source tool Online JWT Verfier.
Open the link above, and paste the value of the id_token into the text area in (Step 1) Set JWT (JSON Web Token) to verify on the JWT Verifier UI. In this tutorial, the value is: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk
Click the Just Decode JWT button in (Step 3) Verify and see decoded content in the Parsed JWT section.
The decoded results are as follows.
Header:
issishttps://authlete.com, which is the default value of Authlete. It must behttps://as.example.com, that is the identifier of the authorization server in this tutorial.subis the only attribute related to the user’s identity. It may be better to include other user attributes for the client’s convenience.
iss value and add other claims in the next section.
Modifying ID token
Issuer identifier
Login to the Management Console https://console.authlete.com and select the Demo AS service previously created during this tutorial. Click the Service Settings button to access the Service Settings. Note that the default value of Issuer Identifier on the General tab ishttps://authlete.com. Change it to https://as.example.com and click the Save Changes button in the bottom of the page.
Now that the Token Issuer Identifier iss has been fixed.
Authorization Request
Let’s make the same authorization request as the previous one (using the samenonce value for convenience) to Authlete’s /auth/authorization API (step #5). Make sure to replace <Service ID>, <Service Access Token> and <Client ID> by your own values generated in the previous step.
Additional claims
Let’s make a request to Authlete’s/auth/authorization/issue for issuance of an authorization code. Make sure to replace <Service ID>, <Service Access Token> and <Ticket> by your own values generated in the previous step.
This time the following additional claims are included on making the request to the API.
You can use the
claims parameter to add claims. The request will be constructed as follows.
GET request to the client.
Token request
The client makes a token request (new lines for readability) to the authorization server./auth/token API.
id_token to textarea in Step 1. In this tutorial, the value is: eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0
Click the Just Decode JWT button in (Step 3) Verify and see decoded content in the Parsed JWT section.
The decoded results are as follows.
Header:
iss value exists, and find the additional claims, name, email and email_verified are included as expected.
Conclusion
In this tutorial, you were able to simulate an authorization server acting as an OpenID Connect Provider, issuing ID Tokens using the authorization code flow with the Authlete API. You completed the following high level steps.- How to use Authlete APIs to implement authorization code flow into authorization server (OIDC identity provider)
- Set issuer identifier values in the Authlete Management Console including additional claims in an authorization request and see them decoded from the ID Token
Next steps
Let’s dig deeper on Authlete by playing with the following features./auth/authorization/failAPI (See Generating error response with “fail” API)/auth/userinfoAPI (See Access token verification in Userinfo API)- Token Management API (See Token Management)
- Authorization server implementations (See Getting Started)
- Signing an ID token with public key cryptography (See Changing signing key for ID token)