Support for Authorization code with PKCE

[andifalk]

According the newest spec of OAuth2 implicit flow is NOT recommended any more ("Must NOT be used")
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#section-7.8

Instead "Authorization code with PKCE" is the recommended one for public clients.
Please also support this Authorization Code Flow with PKCE. Implicit flow is NOT considered as best practice any more.

[manfredsteyer]

Currently, it's just an early proposal and the foundation for a disussion.

The good message is: This lib follows best practices to use it in a safe way and when you combine it with OIDC you get further protections.

So the current strategy is to wait for the final version of this doucment and than decide what's next.

[mmellison]

It would be nice to see this be implemented sooner rather than later.

This isn't a standard we're waiting on, its a BCP. The actual standards for Authorization Code Flow[1] and PKCE[2] are already well established, proposed standards. The BCP is more relevant for determining the default grant types used by libraries, such as this.

[1] https://tools.ietf.org/html/rfc6749, https://tools.ietf.org/html/rfc8252
[2] https://tools.ietf.org/html/rfc7636

[bechhansen]

@seglberg I did an Authorization Code Flow implementation without PKCE, but unfortunately the PR was rejected.

You can have a look at https://github.com/bechhansen/angular-oauth2-oidc
I'm currently not using it so it is currently not maintained.

[mmellison]

Yes! I'm aware of that. 👍
Of course for maintenance reasons it would be beneficial to have it upstream. If its a matter of sponsoring some form of work (or an official fork), we at @arroyonetworks can look into that as well.

[leonardochaia]

https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/

I just wanted to add this here. I consider Brock and Dominick opinion important on this topic.

[manfredsteyer]

The first one is a draft; the second one experimental. Nethertheless, I'll begin to implement it soon.

@bechhansen should we merge our efforts? Back then, I decided against it b/c I wanted to keep this lib as small as possible but things are changing now with those proposals.

[bechhansen]

@manfredsteyer sure. It ought to be fairly easy to merge my stuff to the upstream.
I have still no PKCE implementation though.

[fauxcoding]

@bechhansen I've noticed that you are implementing the refresh tokens as part of the Authorization Code Public Client Flow work.

During my time working with OAuth and OIDC I was always taught to keep refresh tokens away from public clients.

I'd imagine that the majority of users (hopefully everyone) would be using Authorization Code Public Client without refresh tokens and instead renewing their tokens using the silent refresh hack that we currently use with implicit flow.

I'm not sure this library should include the handling of refresh tokens as this might encourage users to implement bad practice.

What are your thoughts on this?

[fabich]

any updates on this?

https://www.identityserver.com/articles/change-in-recommendations-for-browser-based-applications

[foadshariat7]

Any updates?