Configuring an OpenID Connect Provider to enable 2-legged OAuth requests

The typical OAuth flow consists of three legs, or stages of interaction between a client and an authorization server. In 2-legged OAuth scenarios, the client uses pre-authorized scopes so that no interaction with the user is necessary, removing the need to perform one of the legs in the typical flow. Specifically, the user does not need to authenticate to the authorization server or give consent for sharing the information that is specified by the requested scopes. Instead, all requested scope parameters are considered pre-authorized and are automatically added to the request token, which is then sent to the authorization server.

Before you begin

This task expects you to have a Liberty server that is properly configured as an OpenID Connect Provider.

About this task

In scenarios with two legs or stages, an Open ID Connect client can send a 2-legged HTTP request with a grant type of client_credential or resource owner password. These requests do not go through the authorization endpoint, so there is no scope consent form for users to confirm and approve the requested scopes; however the OpenID Connect Provider still needs to deal with the authorized scopes in its access_token content.

Liberty servers that are configured as OpenID Connect Providers that are equipped to handle 2-legged OAuth requests approve the pre-authorized scopes by using the following criteria:

  1. If the grant_type parameter value of a request is client_credential or resource owner password and the request is an OAuth 2.0 request, then all the scopes that are defined in the request are approved and are copied into the content of the access token. This is the existing behavior of the OAuth 2.0 feature.
  2. If the request is an OpenID Connect request or a JWT Token OAuth, or OpenID Connect request, the following criteria is used:
    • If there is no scope parameter that is specified in the request, the OpenID Connect Provider will not accept the request.
    • The requested scopes must be present in the list of scopes that are defined by the scope attribute of the client configuration and must also be specified in the preAuthorizedScope list of the client configuration.

This task demonstrates how to configure a Liberty server that is acting as an OpenID Connect Provider to enable 2-legged OAuth requests.

Procedure

To specify the list of pre-authorized scopes for a client, add the necessary scopes to the scope and preAuthorizedScope attributes of the client configuration within the appropriate <oauthProvider> element in your server.xml file. In the example that is shown, the scopes profile and email are qualified to be specified in the scope list of an access token that is returned by the OpenID Connect Provider. The phone scope is not considered a pre-authorized scope because it is missing from the preAuthorizedScope list. 
<oauthProvider id="OAuthConfigSample" ...>
 ....
           <localStore>           
             <client name="client01" secret="{xor}..."
               displayname="client01"
               scope="profile email phone"
               preAuthorizedScope="profile email"
               enabled="true"/>
             ....
           </localStore>
</oauthProvider>
Note: If a requested scope is not listed in the scope attribute of the client configuration, it is omitted from the scope of the access token that is returned. If a requested scope is listed in the scope attribute of the client configuration but is not included in the preAuthorizedScope list of the client configuration, it triggers an invalid_grant error in the response from the OpenID Connect Provider.