- Log in to the API Store (
- Click My Subscriptions from the menu bar at the top of the screen. The Subscriptions page opens with the following options:
Generate button: Use the Generate button associated with each type of key to generate an access token. It generates an application key and also a consumer key and a consumer secret. For testing purposes, you also can create a sandbox key.
Allowed Domains Text Area:
Allows you to associate a set of domains, as a comma separated list, to a token. API Gateway allows requests to the APIs from those domains only. Others will be restricted. Leave this field blank to allow all domains.
Anchor AllowedDom AllowedDom
With this allowed domains feature, a client from a different domain cannot access an API even if an application key is stolen (when the key is placed in client side JS code). Whenever an API call happens, the Gateway checks if the request originated from an allowed list of domains. This is the same solution done in Google Maps.When the client makes a request to an API that is only allowed to some domains, the request message must have an HTTP header to specify its domain name. APIM admin can configure this header name using in
<APIM_HOME>/repository/conf/api-manager.xml. For example, if the file contains
<ClientDomainHeader>domain</ClientDomainHeader>, then the API invocation request must contain an HTTP header called
domainwith values as shown in the example below:
curl -v -H "Authorization: Bearer xxx" -H "domain: wso2.com" http://localhost:8280/twitter/1.0.0/search.atom?q=cat
Sending this header is mandatory only if the API is restricted to certain domains.
Token Validity Text Area: Set a period in which the token will be expired after generation. Set to a negative value to ensure that the token never expires. Also see Changing the default token expiration time.
To renew a user token, issue a REST call to WSO2 Login API through a REST client. For more information, refer to see Renew User Tokens.
|You can configure the API Manager instances to store access tokens in different tables according to their user store domain. This is referred to as user token partitioning and it ensures better security when there are multiple user stores in the system. For configuration details, see user token partitioning.|