Security

The Development Sandbox Identity Server discovery endpoint can be found here

OAUTH2 - Client credentials grant_type

This is the simplest grant type and is used for server to server communication - tokens are always requested on behalf of a client, not a user.

With this grant type you send a token request to the token endpoint, and get an access token back that represents the client. The client typically has to authenticate with the token endpoint using its client ID and secret.

curl -X POST
http://localhost:5000/connect/token
-H 'Accept: application/json'
-H 'Content-Type: application/x-www-form-urlencoded'
-H 'cache-control: no-cache'
-d 'grant_type=client_credentials&client_id=[client_id]&client_secret=[client_secret]'

OAUTH2 - Resource owner password grant_type

The resource owner password grant type allows to request tokens on behalf of a user by sending the user’s name and password to the token endpoint.

curl -X POST
http://localhost:5000/connect/token
-H 'Accept: application/json'
-H 'Content-Type: application/x-www-form-urlencoded'
-H 'cache-control: no-cache'
-d 'grant_type=password&username=[username]&password=[password]&client_id=[client_id]&client_secret=[client_secret]'

OAUTH2 - Refresh token grant_type

Refresh tokens allow gaining long lived access to APIs.

You typically want to keep the lifetime of access tokens as short as possible, but at the same time don’t want to bother the user over and over again with doing a front-channel roundtrips to IdentityServer for requesting new ones.

Refresh tokens allow requesting new access tokens without user interaction. Every time the client refreshes a token it needs to make an (authenticated) back-channel call to IdentityServer. This allows checking if the refresh token is still valid, or has been revoked in the meantime.

Any access_token returned should be supplied in requests as the Authorization Bearer token value.

Authorization: Bearer [access_token]