OAuth token generation payload : Best Practices

[ksprashu]

While generating OAuth tokens, the policies provides a great deal of flexibility in how the payload is received from the request and can then pass it on to the OAuth policy in the right way.

For example,

1) grant_type can be sent in via query param

2) client / password credentials can be sent in via Headers

3) Everything can be sent as a JSON payload

However the OAuth RFC (https://tools.ietf.org/html/rfc6749#section-4.4.2) explicitly states that the request payload must be sent in as 'application/x-www-form-urlencoded'.

Now the question is about best practices and what is acceptable and what is not.

• Is it ok to prefer convenience over convention and implement the token generation endpoints via JSON, query params etc.
• Maybe we could also support multiple ways of passing in the payload while having form-urlencoded as the primary option
• Or will it be frowned upon if anything other than form-urlencoded is even supported?

What are your thoughts?

[gnanasekaran · Accepted solution]

IMHO - just stick to the spec and also strongly encourage clients to adopt to the spec, there are advantages for both the API developers and API consumers

For API Developers - No need for any additional configuration, the oauth policy supports OAuth to the spec - oob, very simple and easy to setup

For API consumers - RFC is widely known and there are several tools, libs that will just work oob - no need to learn a new way to do OAuth

When you start deviating or supporting other forms - both the parties need to do additional work, then you need to document, manage the lifecycle and support....

I think it is more convenient to stick to the spec

Thanks,

[ksprashu]

Thanks @Mukundha Madhavan, and others. Yup, I agree to the point of sticking to the spec for obvious reasons as stated. Just to prod a little bit more (and I have my reasons 🙂 ), would deviating from the spec be a violation, or just an inconvenience?

[#4]

My advice - as Mukundha says - stick to the spec.