- client_credentials
The client can get an access token without the user authorizing it from the /token endpoint using basic authentication with its id and
secret.
Only for trusted clients. See curl client example. The client secret must be set for this grant type. The admin can specify the roles
the client will have on the resource
servers.
You could imagine a client script with an admin role but only read scope that runs on a trusted server of you and pulls some data
periodically.
- implicit
The client gets a token directly after the user authorizes it. Clients using this should have a rather limited scope.
The client uses the /oauth/authorize?client_id=$clientId&response_type=token&redirect_uri=$uri endpoint to get the code. After
the user authorizes the
client the oauth server will return a redirect to $uri with the token in the hash of the redirect location.
- authorization_code
The user authorizes the client the first time it wants to access resources. In exchange it gets a code to get tokens from the /token
endpoint. Only for trusted clients. The client must have some storage to keep the token.
The client uses the /oauth/authorize?client_id=$clientId&response_type=code&redirect_uri=$uri endpoint to get the code. After the
user authorizes the client the oauth server will return a redirect to $uri with the code in the hash of the redirect location.
The code can then be used at /oauth/token?code=$code&grant_type=authorization_code to obtain a token with it. The client has
to authenticate itself with basic authentication at this point (with its name and the client secret, even when the client_secret grant
is not used!)
- refresh_token
- password
The client asks the user for his credentials and forwards them. Only for clients that you wrote yourself like an official app for a
phone.