Today, after a 10 day vacation at a sunny place, I got back to work and got confronted with basic questions on oauth. Very basic. Questions like these:
- why am I not getting an authorization code when I use 'response_type=token'?
- why is 'SCOPE=openid' ignored when I am using 'grant_type=password'?
If you are asking the same questions, which is nothing to be a shamed about, this blog post is for you.
OAuth request scenarios
To get started we have listed response_types and grant_types at our official CA documentation. Take a look to get an idea when to use what and how to create a request: OAuth request scenarios
OAuth - OpenID Connect - tips
Here are a few tips:
- OpenID Connect requires a flow that starts with a response_type. This means a request is send to the /authorize endpoint. You know that you are not using OpenID Connect if the initial client request includes one of these values:
- request send to the /token endpoint (wrong endpoint)
- ...&grant_type=...& (initial request NEVER with grant_type)
- ...&response_type=token&... (unsupported response_type for OpenID Connect. Find valid response_types here: OpenID Connect response_types)
- OpenID Connect requests MUST include 'SCOPE=openid'. Some of you may say 'I have seen implementations that do not require that'. Yes, but in my personal view that is wrong. The OpenID Connect specification states this:
- OpenID Connect AuthRequest: ... OpenID Connect requests MUST contain the openid scope value. If the openid scope value is not present, the behavior is entirely unspecified ... For me the second sentence is a loop hole and therefore a bad excuse to support OIDC without requiring SCOPE=openid
- OAuth by itself will usually NOT provide information about the current user! If you want your client to display a message such as 'Hello Sascha' you need to leverage OpenID Connect
OAuth - OpenID Connect - rule of thumb
To make it simpler to get an idea what you need to support/ leverage here is a short list with 'Daumenregeln':
- you are exposing an API that does not require an authenticated user: grant_type=client_credentials
- you are maintaining the users credentials (your employee with an enterprise account): grant_type=password
- you want to leverage social login or you do not want the client to provide a login screen: response_type=code
- you want your client to know who the current user is: response_type=code AND scope=openid email profile
You have to answer other questions (like client_type=public or confidential?) but this is a starting point.
OpenID Connect & grant_type=password
Often I get asked how to use OpenID Connect with grant_type=password. By now you should have realized that this is an unsupported combination! However, in most cases the actual requirement is not to combine those two but to also issue an id_token. That, my dear readers, you have to implement yourself! You will not find this as a feature of any certified OpenID Connect provider. To customize OTK you can get help via services or support or a blog post (if there is a high demand).
In any case, please ask yourself: why do I need this? You should not have this requirement! You should be able to use access_token and refresh_token in a combination so that your users are not asked for credentials over and over again.
Please remember, if this is about getting user details, you can include any user information when issuing token since you are in control of the user details anyways!
I hope this short post helps you to get a little head start when looking into these topics. As always, please leave a comment if it was helpful or if you need more help.