As many of you may know, I am the CEO of Authlete.¹Outside Directors²However, I haven't been able to keep up with the latest situation, so IVideo of Mr. Morikawa's seminarI decided to learn about this. The FAPI WG has been working on how to write guidance for implementation behavior when rotating refresh tokens for the past few weeks.

In this video, Morikawa introduced Authlete's features that enable profiling of OAuth and OIDC. The main points are:

1. What is profiling?: Choose the OAuth/OIDC specification yourself and configure the details.
2. Introduction to Authlete: A Web API service for building OAuth/OIDC-compatible authorization servers and identity providers.
3. Token Issuance Context: Background on token lifecycle management and issuance.
4. Client Characteristics: Client attributes are managed in key-value format and used for authorization decisions.
5. Scope Management: Detailed scope management and RAR³Flexible authorization requirements.
6. Entity and message certainty
   • Client authentication: Supports multiple authentication methods
   • Request-Response Authentication: Supports multiple authentication methods (PKCE, PAR, JARM).
7. Resource Owner Intent: Improved security and user experience
8. Characteristics of tokens to be issued: Configure and manage validity periods, attribution, and proof of possession (MTLS, DPoP).
9. Token management after issuance: Rotation and refresh token idempotence.
10. Token Revocation API: Introducing a new API to revoke tokens.

Below, I would like to look at each of them in more detail. Otio AI This is a summary that makes full use of the original video. It also contains some supplementary content.⁴As always, I would appreciate it if you could point out any mistakes.

What is profiling?0:48)

Profiling is the process of making detailed settings and selections required when actually applying OAuth or OIDC. Specifically, it includes selecting what you need from the options provided by the specification, deciding which extension specifications to use from those that came out later, and making various decisions outside the scope of the specification. Typical examples include user authentication and scope settings. Profiling includes the following:

• Detailed configuration and selection work required to actually apply OAuth/OIDC.
• Choose what you need from the options presented in the specification and decide how to use the extension specification.
• There are many decisions that are outside the scope of the specification (e.g. user authentication, scoping).
• This includes deciding on details such as naming and structuring the scope.

Introducing Authlete (1:35)

Authlete is a service that provides components for building authorization servers and identity providers via Web APIs. This allows developers to easily implement complex OAuth/OIDC protocol processing and token lifecycle management. The main features of Authlete are as follows:

1. Provided as a Web API :
   • Authlete provides authorization server functionality as Web APIs, enabling developers to easily invoke authorization processes from their own applications.
2. Authorization and OIDC Engines :
   • Authorization servers and identity providers are often referred to as "authorization engines" and "OIDC engines" because Authlete supports multiple specifications and profiling, giving you the flexibility to choose and implement them freely.
3. OAuth/OIDC Component as a Service :
   • Recently, Authlete is increasingly being introduced as "OAuth/OIDC Components as a Service," which means that Authlete's service goes beyond simply providing APIs, and provides a comprehensive set of components necessary for building and operating an authorization server.
4. Protocol processing and token lifecycle management :
   • Authlete is responsible for checking the parameters of the authorization request it receives and guiding the next step based on the parameters. This flow includes checking the received request information, and if there are no problems, issuing a token and managing its lifecycle.
5. Supports a variety of specifications and profiling :
   • Authlete supports implementations of various OAuth/OIDC specifications and profiling, giving developers the freedom to choose and implement the specifications that best suit their use cases.
6. Knowledge base management :
   • AuthleteKnowledge BaseWe operate an Authlete.org website that provides information on how to use Authlete and its features. This website provides useful information for non-users to design and implement OAuth/OIDC servers.

Authlete provides a comprehensive solution for easily building and operating authorization servers and identity providers. Its distinctive feature is its flexibility in supporting various specifications and profiling, giving developers a high degree of freedom.

Token issuance context (03:42)

The context in which a token is issued is made up of many different elements. Understanding this context helps clarify how the access control and authorization process is structured. The main elements are:

1. Client Characteristics :
   • The authorization server manages many attributes of a client, such as whether the client is a first-party or third-party application, whether it is a confidential or public client, whether it is a web or native application, etc.
   • Authlete manages client attributes in a key-value format and makes authorization decisions using these attribute information when making an authorization request.
2. ス コ ー プ :
   • A scope describes the operation permissions for a resource, but because it is defined as a simple string, it can be difficult to manage detailed permissions as is.
   • Authlete provides a scope attribute feature that allows you to associate arbitrary information with a scope in key-value format. It also allows you to configure restrictions on the scopes that can be requested by each client.
3. Entity and message certainty :
   • This includes client authentication and request-response protection (e.g. PKCE, PAR, JARM, etc.).
   • It supports settings for client authentication method and protection method of request parameters.
4. Resource Owner Intent :
   • You can present the scopes requested in the authorization request to the end user and let them choose which scopes to allow. This implementation can also be built using Authlete's APIs.
5. Token Lifecycle :
   • Manage the lifecycle of access tokens and refresh tokens, from issuance to use, updating, invalidation, and deletion.
   • We also provide a function that allows you to set the validity period of each token per authorization server, per scope, and per client.
6. Proof of Possession (PoP) :
   • By using MTLS and DPoP, we provide a mechanism to prove that the user of the access token is its legitimate owner.

Authlete helps manage the complex authorization process and token lifecycle through these elements. With a wide range of configurations and features for authorization decisions and token management, developers can choose and implement the configuration that best suits their application.

Client characteristics (05:20)

The characteristics of the client play an important role when the authorization server issues tokens. In particular, the following factors are taken into account:

1. Management entity :
   • First-party applicationsとThird Party ApplicationsDistinction.
   • First-party applications are those that are directly controlled by the developer, while third-party applications are those that are provided by a third party.
2. Client Type :
   • Confidential ClientとPublic ClientDistinction.
   • A confidential client is a client (server-side application) that can securely hold a client secret (private key).
   • Public clients are clients that cannot keep a client secret securely (such as native applications or single page applications).
3. Application form :
   • Web Applications,Native Applications,Single Page Application (SPA)The characteristics vary depending on the type of client.
4. Client Attribute Management :
   • In Authlete, arbitrary attributes can be set for each client.Key-Value FormatIt provides the functionality to manage.
   • This allows you to flexibly process authorization requests based on the information set as client attributes.
5. Handling Authorization Requests :
   • The authorization server refers to the client ID included in the authorization request received from the client and checks the client attributes associated with the client ID.
   • This client attribute information is used to make authorization decisions.

Client attribute setting example

In the Authlete administration console, you can configure client attributes as follows:

• key:affiliation
• value:partner

Based on this information, the authorization server can apply processing that is specific to the particular client.

Example :

• First-party clients(In-house apps): Allow requests for highly privileged scopes.
• Third Party Clients(Third-party apps): Only limited scope is allowed.

That's an overview of client characteristics and how to manage and utilize them.Client Attributes KBSee.

Scope Management (07:02)

In OAuth and OIDC, a scope is a parameter that expresses the authority to access a resource. Scope management is an important element for controlling the level of access a user or client has by setting or restricting the scope. Authlete provides several functions related to scope management:

1. Basic structure of scope :
   • Scope parametersScopes are simply defined as strings and include them in requests to request specific permissions. However, the name of a scope as a string alone may not be enough to express the detailed permissions that the scope has.
2. Structuring scope :
   • Scope Attributes: Authlete provides a "scope attribute" feature that allows you to associate arbitrary information with a scope in key-value format. This allows you to manage detailed metadata about a scope.
   • Scope Examples :
     • Scope name:read_profile
     • Scope Attributes: Key-Value (e.g. keylevel,valuehigh）
   You can configure detailed settings for each scope using the UI on the administration screen.
3. Per-client scope limits :
   • Authlete provides a function to restrict the scopes that can be requested by each client, allowing you to have fine-grained control over the scopes that a specific client can use.
   • An example: Client A has the scoperead_profileOnly allowed, client B has scoperead_profileとedit_profileallow.
4. Dynamic Scope :
   • Dynamic Scope: A technique for parameterizing scope names. For example,consent:12345Use the scope name plus additional information, for example:
   • Regular expression: You can use regular expressions for scope names to dynamically generate scope names that meet your requirements. Authlete allows you to manage dynamic scopes by specifying regular expressions as scope attributes.
5. Rich Authorization Request (RAR) :
   • RAR (Rich Authorization Requests): An extension specification that enables more detailed and flexible authorization requests than scopes.authorization_detailsUse parameters to specify finer grained access permissions.
   • With Authlete, you can configure this RAR on a per-client basis, enabling detailed permission management.

Scope management implementation example

In the Authlete administration console, you can set scopes and attributes as follows:

• Scope name:read_profile
• Attribute Key:level
• Attribute Value:high

This allows the scoperead_profileThis allows for detailed management of

Entity and message certainty (10:06)

Client authentication (10:50)

Client authentication is an important mechanism for a client to communicate securely with an authorization server. Client authentication is required at the token endpoint, especially for confidential clients. Specifically, this includes the following:

1. Selecting an authentication method

• There are mainly two ways to authenticate clients:
  • Client SecretThis is the most basic method and uses a client ID and a client secret (the equivalent of a password).
  • Client Certificate (mTLS): Mutual TLS is established using a client certificate for authentication.
  • JWT-based: A client authentication method using JSON Web Token (JWT).
  • Other: Some clients may require special methods for their devices.

2. Configuration in Authlete

• Authlete allows a service (authorization server) to define a set of client authentication methods it supports. This configuration allows the authorization server to decide which authentication methods to allow.
• Client Configuration: Set which authentication method to use for each client. This allows you to select the appropriate authentication method for each client and ensure a high level of security.

3. Features provided by Authlete

• Authentication method enforcement: Authlete provides the functionality to enforce the use of authentication methods, including the configuration to force a specific authentication method for all clients.
• Flexible configuration at both the service and client level allows authentication according to security requirements.

4. Example :

• Service Settings: In the Authlete management console, specify the client authentication methods supported by the authorization server (e.g.client_secret_basic,client_secret_post,client_secret_jwtand so on).
• Client ConfigurationIn the individual client settings, you select the authentication method that the client will use from the methods above. For example,client_secret_basicand in another clientclient_secret_jwtIt is possible to configure it to use.

In addition, although it is not a so-called client authentication, PKCE [RFC7636] is required for public clients and is also required even if the client is not public.⁵We also provide support for:

Request-Response Authentication (12:02)

For request-response authentication, PKCE, PAR and JARM are supported.

PKCE (12:02)

Overview

• DescriptionPKCE is an extension to the OAuth 2.0 Authorization Code Flow that is designed to improve security for public clients.
• Reasons for introduction: This reduces the risk of authorization codes being stolen by public clients (such as mobile apps and single-page applications) that cannot securely store client secrets.

How it works

• Code ChallengeWhen a client makes an authorization request:code_challengeSend the parameter.
• Code VerifierIn subsequent token requests, the clientcode_verifierThe authorization server sendscode_verifierThecode_challengeIf it matches, a token is issued.

Authlete Support

• Enforcement: Authlete has a setting to enforce the use of PKCE. For example, you can require all clients to use PKCE.
• Specifying the challenge method : S256It is also possible to enforce a code challenge method such as

PAR [RFC9126] (13:36)

Overview

• Description:PAR is a specification for registering authorization request parameters in advance with an authorization server and protecting them, reducing security risks that arise when authorization requests are sent via a user agent (browser).
• Reasons for introduction: This is a mechanism to prevent authorization request parameters from being tampered with if they are exposed to the frontend.

How it works

• Pre-registration: Send all authorization request parameters, including client authentication, to the authorization server in advance.
• Request URI: The authorization server returns a request URI and makes an authorization request using that URI.

Authlete Support

• Dedicated API: Authlete provides a dedicated API for handling PAR requests, making it easy for authorization servers to implement PAR.

JARM (14:43)

Overview

• Description：JARM⁶is a specification for protecting authorization responses in JWT format, thereby ensuring the integrity and authenticity of authorization responses.
• Reasons for introduction: The contents of the authorization response are encrypted and signed to prevent the risk of it being tampered with during transmission.

How it works

• JWT FormatThe authorization server returns an authorization response as a signed and possibly encrypted JSON Web Token (JWT).
• Response ValidationWhen the client receives the response, it validates the JWT to ensure its integrity and the validity of its issuer.

Authlete Support

• Multiple Signature Algorithms: Authlete supports multiple signature and encryption algorithms for JARM responses.
• Flexibility in configuration: You can set the use of JARM for each client.

Resource owner intent (15:13)

Resource owner intent refers to the process by which a resource owner (usually an end user) clarifies which scopes they will allow when an authorization request is sent. By using Authlete, you can build flexible authorization flows that reflect the resource owner's intent.

1. Basic Ideology

• User Participation: Presents the resource owner with the scopes to include in the authorization request and lets them choose which scopes to allow.
• Flexible Permissions: Resource owners can grant only specific scopes, preventing over-granting.

2. Implementation method

• Using Authlete APIs: You can customize the authorization request process and allow the resource owner to check and select scopes in a user interface (UI) that you create.
• Knowledge Base Guides : Authlete Knowledge Basedetails the specific steps to implement this.
  • Presents the scopes requested in the authorization request to the end user.
  • Select the scopes that you want to allow for end users.
  • Based on the selection, the final authorization response is generated.

3. Example :

• Presenting an Authorization Request :
  1. Receives an authorization request from a client.
  2. The scope requested by the resource owner (e.g.read_profile,edit_profile) is displayed on the UI screen.
  3. If the resource owner grants access to a specific scope (e.g.read_profileSelect "Only."
• Scope Allowance and Response :
  1. The final scope is determined based on the resource owner's selection.
  2. Generate an authorization response with the selected scopes.
  3. Include only selected scopes in the authorization token.

4. Use the knowledge base

• Specific Code and Guide :
  • Authlete Knowledge Basecontains concrete API usage examples and code samples for implementing these processes.
  • Implementation details and step-by-step guides are provided, allowing you to efficiently proceed with development.

Designing an authorization flow that reflects the resource owner's intent provides more fine-grained control to end users, improving security and user experience. By leveraging Authlete's features, this process can be implemented smoothly.

Now that we have achieved the step of issuing tokens, we will explain the characteristics of the tokens that will be issued.

The characteristics of the token to be issued (16:05)

Valid period

• How to decide: The token lifetime can be set for each authorization server, scope, and client. You can also specify a specific lifetime as a request parameter when issuing a token.
• Priority: If multiple conditions are met, the shortest validity period will be applied.
• Flexibility in configuration: Authlete allows you to set the validity period for each token in granularity down to the second, and also provides an API that allows you to dynamically change the validity period to meet certain conditions when issuing tokens.

Token Attributes

• Overview: You can associate any attribute with the token in key-value format.
• Representative attributes: Client ID, user identifier, scope, client classification, user role, etc.
• Use: Used by resource servers to validate tokens not just to determine whether they are valid, but also to obtain more information about the token's origin and context.

How to attach arbitrary properties to a tokenKnowldege BaseSee.

Passing attributes to a resource server

• Access token format :
  • Identifier Types: The resource server introspects the token to obtain information.
  • Self-contained: The attribute information is embedded directly into the token itself.
  • Hybrid type:An approach that combines the advantages of the above two.

Proof of Possession

• MTLS (Mutual TLS) :
  • How it works: Authentication is performed using a TLS client certificate, and the token and client certificate are bound. The authorization server checks whether the certificate has been registered in advance. The resource server also checks the certificate.
  • Issuing TLS client certificate-bound access tokens reference
• DPoP (Demonstrative Proof of Possession) :
  • How it works: A public/private key pair is used to generate a DPoP Proof JWT and bind it to an access token. This is a mechanism to achieve proof of possession at the application layer.
  • Configuration: Authlete allows you to configure the enforcement of DPoP on a client-by-client basis.
  • Using DPoP reference

Token management after issuance (22:38)

Refresh Token Continuation and Rotation

• Continued use: A setting that continues to use the refresh token value as is without updating it.
• rotation(Do not continue using): Update the refresh token value and issue a new token. The value changes every time you refresh the token.
• Reset validity period: When updating the refresh token value, you can choose whether to reset the validity period. If you reset it, the validity period will start again.
• Validity period transfer: The expiration time of the new refresh token will be set to the expiration time of the old refresh token.
• For details, Refresh token continuous use setting It is in

Refresh Token Idempotence (24:27)

• Concurrent token refresh problem: When the token value is set to update, the refresh token value is updated every time a token refresh is performed. In this case, if multiple token requests come from multiple clients within a short period of time, all requests except the first one will result in an invalid token error.
• Solutions: Authlete mitigates this issue by setting refresh token idempotence, which means that if there are multiple refresh requests using the same refresh token within a short period of time, the same new refresh token is returned for all requests.

Token Revocation API (26:02)

The Token Revoke API provides the ability to revoke a specific token or all associated tokens based on certain conditions, which is important for maintaining security and preventing unwanted token usage.

1. Basic functions

• Individual Token Revocation: You can revoke a specific access token or refresh token.
• Termination based on conditions: You can revoke all tokens associated with a particular client or resource owner.

2. How to request revocation

• Client Request :
  • Compliant with RFC 7009: A standard specification for invalidating a token by specifying the value of an access token or refresh token.Implementation method: The client revokes a specific token by using Authlete's token revocation API.

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

• Request from resource owner/authorization server :
  • Termination based on conditions: Revokes all tokens (access tokens and refresh tokens) associated with a client or resource owner at once.
  
  
  • Using the API: Authlete's new token revocation API allows for more flexible configuration of revocation conditions.

     POST /api/auth/token/revoke
     Host: api.authlete.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     {          "subject": "リソースオーナーの識別子", 
          "client_id": "クライアントID"
     }

3. Usage example

• Example 1When a user changes their password, revoke all access and refresh tokens associated with that user.
• Example 2If a client application is found to be misbehaving, all tokens associated with that client can be revoked at once.

4. Expiration and Token Management

• Expired tokens: Token expiration processing basically applies to tokens that are within their expiration date, but tokens that have passed their expiration date also need to be managed, such as by deleting them from the database.
• Handling after expiration: Expired tokens cannot be reused and resource servers will perform introspection to check token validity.

---

Authlete's token revocation API provides the flexibility and security to handle a wide range of scenarios, enabling safe and effective token management.

My Feelings, Then and Now

• Profiling OAuth/OIDC requires consideration of the authorization history, resource server request information, lifecycle management, and security measures.
• Best Current Practice (BCP) or FAPI, etc.
• Authlete's Templates,API ReferenceYou can refer to

1. Authlete supports highly secure OAuth/OIDC implementations and also promotes standards such as FAPI (Financial-grade API).
2. They also help us implement new specifications one after another, so I am participating as an outside director.
3. Rich Authorization Request
4. Otio is supposed to create materials using only the target documents, but when a video is loaded, it is converted into text by GPT-4o, so it appears that the information is supplemented at that time.
5. Reading: Pixie (fairy)
6. JWT Secured Authorization Mode