I didn’t like Nat’s Fixing OAuth? post.
“For protecting a resource with low value, current RFC6749 and RFC6750 with an appropriate constraint should be good enough…For protecting a resource whose value is higher than a certain level, e.g., the write access to the Financial API, then it would be more appropriate to use a modified protocol.”
I agree that write access to a financial API is a high value operation (and security measure will go far beyond authentication and token requests) – but most users and implementers of OAuth 2.0 based system would surely disagree that their resources only have a low value.
Then on the other hand I agree that OAuth 2.0 (or rather RFC6749 and 6750) on its own indeed has its issues and I would advise against using it (important part “on its own”).
Instead I would recommend using OpenID Connect – all of the OAuth 2.0 problems regarding client to provider communication are already fixed in OIDC – metadata, signed protocol responses, sender authentication, nonces etc.
When we designed identity server, we always saw OpenID Connect as a “super-set” of OAuth 2.0 and always recommended against using OAuth without the OIDC parts. Some people didn’t like that – but applying sound constraints definitely helped security.
I really don’t understand why this is not the official messaging? Maybe it’s political?
(no response)
Wrt to the issues around bearer tokens – well – I really, really don’t understand why proof of possession and HTTP signing takes that long and seems to be such a low priority. We successfully implemented PoP tokens in IdentityServer and customers are using it. Of course there are issues – there will always be issues. But sitting on a half done spec for years will definitely not solve them.
So my verdict is – for interactive applications, don’t use OAuth 2.0 on its own. Just use OpenID Connect and identity tokens in addition to access tokens – you don’t need to be a financial API to have proper security.
leastprivilege.com 
When you say “don’t use OAuth 2.0 on its own”, would you also advise against the resource owner password grant type for first party native applications (mobile)?
I understand this grant type isn’t part of OIDC, do you see any issues in supporting id tokens in this flow?
There are many other reasons why I wouldn’t necessarily recommend resource owner flow – but from a security point of view, the problems are well understood.
There are no id tokens in that flow.
Yep, I understand some the main reasons in not necessarily recommending the resource owner flow and that there are no id tokens in that flow, but what are the potential security risks in supporting id tokens as auth0 do? https://auth0.com/docs/protocols#oauth-resource-owner-password-credentials-grant
That you are inventing your own protocol. And I don’t get that. They are not necessary.
Request an access token including identity scopes and send that to the userinfo endpoint for validation and retrieving claims.
That’s fair enough and I agree.
What’s tough re OIDC on native is convincing UX and mobile devs that it’s not so bad having an almost once off redirect to web view for login (inc partial flows) when the majority of top rated apps have native logins :( Then the argument arises of “OIDC is only for third parties, we don’t need”, so let’s invent our own protocol on top of it :)
Resource owner has a place for 1st party apps – as long as you are aware what you are missing (like SSO, federation etc).
I don’t see a point in “inventing” id tokens for resource owner though.
I’ve watched your talk, it’s a very good overview thank you for that.
We’re using idsrv and have a migration process as part of our partial auth flow (including other steps not related to migration), I don’t see the point in “re-inventing” this for native using resource owner and going down the path of supporting “partial tokens” in the same way we have “partial auth cookies”.
We are using IdentityServer3 Framework to implement OAuth2. You mention that the important part is that we should ensure we use the OIDC parts for enhanced security.
I am not sure as to how this is done. Is it by ensuring the clients use the IdentityModel.OidcClient instead of IdentityModel.Client? Is it possible to force Identity Server to only support OAuth2 using the OIDC parts?
You have to use OIDC – depends on your use case how you would do that.
In our scenario we are using Resource Owner flow. Is it possible to force the clients to user OIDC only from the server side.
In our scenario we are using Resource Owner flow. Is it possible to force the clients to user OIDC only, by configuring this on the IdentityServer. Made a new comment to prevent misinterpretation.
RO flow is not part of OIDC. so no.
But RO flow does not have the same problems because no user interaction is involved. It has different shortcomings though (more feature wise).
Sorry I missed your tweet.
My advice obviously is to use OIDC if it is politically ok. There seems to be people who are not though.