Versions Compared

Old Version 3

changes.mady.by.user Former user

Saved on

compared with

New Version 4

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated the non-authentication section

Let's take a look at some concepts and terminology that you need to know in order to follow the use cases.

...

Response content typeYou can use the Produces attribute to document in what type the backend sends the response back to the API Manager. Note that this attribute does not do any message type conversion, it is only used as a way of letting the user know the type of response they will receive. You can define the response content type in the Design tab when creating an API.
ParametersParameters of an HTTP method are analogous to arguments of a function in an object-oriented programming language. A resource's parameters are cached in the resource cache at the API Gateway. You can define the parameters in the Design tab when creating an API.

OAuth scopes

You can define a list of OAuth scopes to an API's resource and assign one of them to each HTTP method. You can define the OAuth scopes in the Manage tab when creating an API as shown above.

Authentication type

You can set the response content type by navigating to the Manage tab, when creating an API, and select the corresponding authentication from the "Application & Application user" drop-down list, which corresponds to the respective resource.

The authentication type can be one of the following:

  • None: You

need to

  • can select this option

when you want to

  • to create a non-authenticated API. This will remove the authentication requirements for regular managed APIs, so that the API Gateway skips the authentication process. This is useful in instances when you want to still have the API listed on the API Store home screen and/or when you want to disable authentication requirement for individual resources of an API.

  • Application: The authentication is done by the application and the resource accepts application access tokens. Therefore, if you select this option, the API will require OAuth tokens generated with a client grant type that produces tokens specific to the subscription, but not the end-users. Therefore, if there is a web or mobile application that has subscribed to this API and it has multiple end-users, then they will all share the same token and the API backend will not know which end-user invoked the API.


  • Application User: Authentication is done by the application user and the resource accepts user access tokens. Therefore, if you select this option, the API accepts the OAuth tokens that are generated with the password grant type. These tokens are specific to the end-user, because they not just require the application key, but also the end-user’s username and password. In this case, each end-user gets their own OAuth tokens even though they are using the same API subscription. The API Gateway then generates a JWT token and uses it to pass application and user information to the API backend.

  • Application and Application User: Both application and application user level authentication is applied. Thereby, both kinds of tokens are acceptable by the API.
    Note that if you select this option in the UI, it appears as Any in the API Manager's internal data storage and data representation, and Any will appear in the response messages as well.
Note

Note that for the resources that have HTTP verbs (GET, POST etc.) requiring authentication (i.e., Auth Type is not NONE), set None as the Auth type of OPTIONS. This is to support CORS (Cross Origin Resource Sharing) between the API Store and Gateway.

The auth type is cached in the API Manager for better performance. If you change the auth type through the UI, it takes about 15 minutes to refresh the cache. During that time, the server returns the old auth type from the cache. If you want the changes to be reflected immediately, please restart the server after changing the auth type.


...

Cross-origin resource sharing

Cross-origin resource sharing ( CORS ) is a mechanism that allows restricted resources (e.g., fonts, JavaScript) of a Web page to be requested from another domain outside the domain from which the resource originated.

The Swagger API Console that is integrated in the API Manager runs as a JavaScript client in the API Store and makes calls from the Store to the API Gateway. Therefore, if you have the API Store and Gateway running on different ports, enable CORS between them. 

...

Code Block
languagexml
<handlers>
   <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.CORSRequestHandler"/>
</handlers>

...

OAuth scopes

Scopes enable fine-grained access control to API resources based on user roles. You define scopes to an API's resources. When a user invokes the API, his/her OAuth 2 bearer token cannot grant access to any API resource beyond its associated scopes.

Info

OAuth provides a method for clients to access a protected resource on behalf of a resource owner. OAuth 2 bearer token is a security token that any party in possession of it can use the token for authentication. Refer OAuth 2.0 Specification of Bearer Token Usage for more information.

How scopes work

To illustrate the functionality of scopes, assume you have the following scopes attached to resources of an API: 

...