Page Comparison

Users need access tokens to invoke APIs subscribed under an application. Access tokens are passed in the HTTP header when invoking APIs. The API Manager provides a Token API that you can use to generate and renew user and application access tokens. The response of the Token API is a JSON message. You extract the token from the JSON and pass it with an HTTP Authorization header to access the API.

...

1. Combine the consumer key and consumer secret keys in the format consumer-key:consumer-secret and encode the combined string using base64. Encoding to base64 can be done using the URL: http://base64encode.org.
   Here's an example consumer key and secret combination : wU62DjlyDBnq87GlBwplfqvmAbAa:ksdSdoefDDP7wpaElfqvmjDue.
2. Access the Token API by using a REST client such as the WSO2 REST Client or Curl, with the following parameters.
   
   • Assuming that both the client and the API Gateway are run on the same server, the token API url is https://localhost:8243/token
   • payload - "grant_type=password&username=<username>&password=<password>&scope=<scope>". Replace the <username> and <password> values as appropriate. <scope>
      <scope> is optional, you can leave it off if necessary. And if you have multiple scopes, add them all seperated by a space.
   • headers - Authorization: Basic <base64 encoded string>, Content-Type: application/x-www-form-urlencoded. Replace the <base64 encoded string> as appropriate.          

   For example, use the following cURL command to access the Token API. It generates two tokens as an access token and a refresh token. You can use the refresh token at the time a token is renewed .

   Code Block
   curl -k -d "grant_type=password&username=<username>&password=<password>" -H "Authorization: Basic SVpzSWk2SERiQjVlOFZLZFpBblVpX2ZaM2Y4YTpHbTBiSjZvV1Y4ZkM1T1FMTGxDNmpzbEFDVzhh" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:8243/token

   Code Block
   title CuRL command with Scopes
   curl -k -d "grant_type=password&username=<username>&password=<password>&scope=<scope1> <scope2>" -H "Authorization: Basic SVpzSWk2SERiQjVlOFZLZFpBblVpX2ZaM2Y4YTpHbTBiSjZvV1Y4ZkM1T1FMTGxDNmpzbEFDVzhh" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:8243/token

   Tip
   Tip: If you define a scope for an API's resource, the API can only be accessed through a token that is issued for the scope of the said resource. For example, if you define a scope named 'update' and issue one token for the scopes 'read' and 'update', the token is allowed to access the resource. However, if you issue the token for the scope named 'read', the request to the API will be blocked.

   Warning
   The Token API endpoint is specified in <APIM_HOME>/repository/deployment/server/synapse-configs/default/api/_TokenAPI_.xml file. When running the server on a different port from the default (i.e., 9443), or if your Key Manager is running on a different machine from your API Gateway, you must update the endpoint inside the _TokenAPI_.xml file as described in the prerequisites.

   Info
   icon false
   User access tokens have a fixed expiration time, which is set to 60 minutes by default. Before deploying the API manager to users, extend the default expiration time by editing the <AccessTokenDefaultValidityPeriod> tag in <PRODUCT_HOME>/repository/conf/identity.xml. When a user access token expires, the user can try regenerating the token as explained in the Renew user tokens section.

...

Exchanging SAML2 bearer tokens with OAuth2 (SAML extension grant type)

SAML 2.0 is an XML-based protocol. It uses security tokens containing assertions to pass information about an end-user between a SAML authority and a SAML consumer. A SAML authority is an identity provider (IDP) and a SAML consumer is a service provider (SP).

Enterprise applications use SAML2 to engage a third-party identity provider to grant access to systems that are only authenticated against the enterprise application. These enterprise applications might need to consume OAuth-protected resources through APIs, after validating them against an OAuth2.0 authentication server. However, an enterprise application that already has a working SAML2.0 based SSO infrastructure between itself and the IDP prefers to use the existing trust relationship, even if the OAuth authorization server is entirely different from the IDP. The SAML2 Bearer Assertion Profile for OAuth2.0 leverages this existing trust relationship. It presents the SAML2.0 token to the authorization server and exchanges it to an OAuth2.0 access token.

WSO2 API Manager provides SAML2 Bearer Assertion Profile Support with the OAuth 2.0 feature. WSO2 Identity Server  (version 4.5.0 onwards) or any other SAML2 Identity provider can act as an identity service provider for the systems enabled with SSO. WSO2 API Manager acts as the OAuth authorization server. This way, an enterprise application can exchange the SAML2.0 bearer token that it retrieves when authenticating against an IDP (e.g., WSO2 Identity Server) with an OAuth2.0 access token from an OAuth authorization server (e.g., WSO2 API Manager). It can then use the OAuth2 token in API invocations.

The diagram below depicts this scenario:

Image Modified   
The scenarios of the above diagram are explained below:

Scenario [1]: User initiates login call to an enterprise application .

Scenario [2]:

• As the application is a SAML SP, it redirects the user to the SAML2.0 IDP to log in.
  
• The user provides credentials at the IDP and is redirected back to the SP with a SAML2.0 token signed by the IDP.
  
• The SP verifies the token and logs the user to the application.
  
• The SAML 2.0 token is stored in the user's session by the SP.  

Scenario [3]:

• The enterprise application (SP) wants to access an OAuth2 protected API resource through WSO2 API Manager.
• The application makes a request to the API Manager to exchange the SAML2 bearer token for an OAuth2.0 access token.
• The API Manager validates the assertion and returns the access token.

Scenario [4]: User does API invocations through the API Manager by setting it as an Authorization header with the returned OAuth2 access token.

Before you configure the token exchange, do the following:

• Register to a valid user account in the API Store.
  
• Get a valid consumer key and consumer secret. Initially, these keys must be generated through the management console by clicking the Generate link on My Subscriptions page. For more information, see Invoke an API using the Integrated REST Client. 
  
• Set up a running API Gateway instance.
  
• If you have multiple WSO2 servers (such as WSO2 API Manager and WSO2 Application Server) running on the same machine, change the port offset and update the token API's endpoint accordingly. Additionally, if the key manager is on a different server from the API Gateway, update the token API endpoint to use the correct host and port. For more information, see this prerequisite in the previous section.

Configuring the token exchange

We use WSO2 Identity Server 5.0.0 as the IDP to get a SAML token and the API Manager as the OAuth server.

1. Log in to the API Manager's management console (https://localhost:9443/carbon) using admin/admin credentials and select Add under Identity Providers menu in the Main menu. 
   
2. Provide the following values to configure the IDP:
   
   • Under Basic Information 
     
     • Identity Provider Name: Enter a unique name for IDP

     • Identity Provider Public Certificate: Export the public certificate of WSO2 IS and import it here.
       Alternatively, you can create a self-signed certificate and then export it as a .cer file using the following commands: 
       

       Code Block
       keytool -genkey -alias wookie -keyalg RSA -keystore wookieKeystore.jks -keysize 4096 keytool -v -export -file keystore1.cer -keystore keystore1.jks -alias keystore1

        

     • Alias: Give the name of the alias if the Identity Provider identifies this token endpoint by an alias. E.g., https://localhost:9443/oauth2/token

   • Under Federated Authenticators -> SAML2 Web SSO Configuration

     • Enable SAML2 Web SSO: true
       

     • Identity Provider Entity Id: The SAML2 issuer name specified when generating the assertion token, which contains the unique identifier of the IDP. You give this name when configuring the SP.

     • Service Provider Entity Id: Issuer name given when configuring the SP
     • SSO URL: Enter the IDP's SAML2 Web SSO URL value. E.g., https://localhost:9444/samlsso/ if you have offset the default port, which is 9443.
    
3. Log in to the management console of the Identity Server and select Add under Service Providers menu in the Main menu.
   
4. Choose to edit the service provider that you just registered and select SAML2 Web SSO Configuration.
    
5. Provide the following values to configure the SP:
   
   • Issuer: Give any name
   • Assertion Consumer URL: The URL to which the IDP sends the SAML response. E.g., https://localhost:9443/store/jagg/jaggery_acs.jag
   • Enable Response Signing: true
   • Enable Assertion Signing: true
   • Enable Audience Restriction: true
   • Audience: URL of the token API. E.g., https://localhost:9443/oauth2/token
     
   
    Let's see how to get a signed SAML2 token (encoded assertion value) when authenticating against a SAML2 IDP. With the authentication request, you pass attributes such as the SAML2 issuer name, token endpoint and the restricted audience. In this guide, we use a command-line client program to create the SAML2 assertion.

6. Get the SAML token using the client JAR.
   An example command is given below. TestSP is the name of the issuer. 
   

   Code Block
   java -jar SAML2AssertionCreator.jar TestSP admin https://localhost:9443/oauth2/token https://localhost:9443/oauth2/token /home/dinusha/nothing/WSO2/API-Manager/saml-oauth/wso2is-5.0.0/rhbepository/resources/security/wso2carbon.jks wso2carbon wso2carbon wso2carbon

   You receive the consumer key and consumer secret.

7. Anchor
   step7 step7

   Retrieve the encoded assertion string.
   Use the following format in a base64-url encoder (e.g., https://www.base64encode.org/) to encode the consumer key and consumer secret that you received in step 6. 
   

   Code Block
   <consumer-key>:<consumer-secret>

    

   
   

    

8. Retrieve the OAuth Access token.
   Use the base64-url Encoded Assertion String that you derived in step 7 as the value for <ASSERTION_PROVIDED_BY_CLIENT> in the following command.

   An example command is given below.
   

   Code Block
   curl -k -d "grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=<ASSERTION_PROVIDED_BY_CLIENT>&scope=PRODUCTION" -H "Authorization: Basic <ASSERTION_PROVIDED_BY_CLIENT>, Content-Type: application/x-www-form-urlencoded" https://localhost:9443/oauth2/token

...

• The token to be revoked
• Consumer key and consumer secret key. Must must be encoded using Base64 algorithm.

For example, curl -k -d "token=<ACCESS_TOKEN_TO_BE_REVOKED>" -H "Authorization: Basic Base64Encoded(Consumer key:consumer secret)" http://localhost:8280/revoke.

...

You configure the time stamp skew using the <TimestampSkew> element in <PRODUCT_HOME>/repository/conf/identity.xml. 

Ideally, the time stamp skew should not be larger than the token's life span. Also, note that when the API Gateway cache is enabled (it is enabled by default), even after a token expires, it will still be available in the cache for consumers until the cache expires in approximately 15 minutes.