Angular-auth-oidc-client: Support for authorization code flow

[b-wins]

Hi -

Because of my application structure, I'm looking to use authorization code flow and pass the code to a backend server which will take over from there.

Does this library have any way to support that? Or ideas of a different one you played with?

Thanks,

B Wins

[damienbod]

Hi @b-wins
No This library is for SPA angular applications. Angular applications should use the OIDC Implicit Flow. Server tech. libs which support OIDC, can support the authorization code flow. Which tech do you use?

Greetings Damien

[b-wins]

I have an Angular SPA however my use case is not the typical. My SPA talks to a secured RESTful API which is secured with a pretty complex system. It generates its own JWT when it receives either a username/password or an auth code that it exchanges for a valid token.

[damienbod]

You could take the src code, and create you custom case yourself.

Greetings Damien

[damienbod]

@b-wins I'm going to close this as the lib will not support this flow. SPAs should always use the OpenID Implicit Flow, and I do not want to confuse people with custom flows.

Please reopen, or comment further if you need something.

Greetings Damien

[matt-psaltis]

With Angular support in Native app frameworks such as Ionic and NativeScript, it would be great if this could be reconsidered. There's a lot of discussions recently about moving away from Implicit flow even for SPAs.

[damienbod]

@SaltyDH Yes, native apps should always use the authorization Code Flow with PKCE... I was thinking about this, but AppAuth does this good (Android, IOS). At present no solution exists for doing Angular apps and native apps securely from one code base.

The best solution for doing security in an SPA is an implemention using the OIDC Implicit Flow specification, other solutions/suggestions, examples are not the recommended way. There are lots of angular security examples doing this insecurely with bad recommendations.

[matt-psaltis]

Thanks @damienbod. I seem to have stumbled across the bad examples over the past few days! We're doing a lot of code sharing between mobile and browser based Angular apps and I have been looking for that unified solution which allows me to use one flow for browser and mobile alike - reduction in testing and code maintenance being the main driver.

[ttothebrown]

@damienbod You should look here:

Directly from Oauth's site: https://oauth.net/2/grant-types/implicit/

So the information you are basing this on is outdated.

SPA specific: https://aaronparecki.com/oauth-2-simplified/#single-page-apps

[damienbod]

@ttothebrown really interesting, thanks for the links. I ask around for some opinions

[damienbod]

there has been no formal guidance from the spec committee on this:
https://mailarchive.ietf.org/arch/msg/oauth/lhIUyUpuueJmYMT8FwmIlqp6T2g …

And this is the website you should be reading for OAuth2 guidance: https://tools.ietf.org/wg/oauth/

[ttothebrown]

@damienbod thank you for the resource. So it looks like they are considering it, but there's more implications that need to be thought out. For now, I'll fork your repo and see about implementing code flow to it as everything they have stated regarding security concerns is already things we are taking into account.

[andifalk]

@b-wins I'm going to close this as the lib will not support this flow. SPAs should always use the OpenID Implicit Flow, and I do not want to confuse people with custom flows.

Please reopen, or comment further if you need something.

Greetings Damien

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. This mitigates token leakage problem of the browser.

[damienbod]

Hi @andifalk yes, I'm following this discussion. The specs is a first draft with lots of open issues and the recommendations are just an opinion. When the draft becomes supported from the IETF and the problems with this flow are solved, then great.

I will re open this, and start supporting this flow soon. There is a lot of noise about this at the moment, but this opinion is still not standard or best practice. A lot of stuff in this draft also exists when using OIDC Implicit Flow with CSP. The doc compares with OAuth2 Implicit Flow.

I continue to follow the discussions and recommendations about this.

Thanks for your comment.

"This mitigates token leakage problem of the browser." Yes this would be an improvement, but the main problem is the storing of the tokens in the unsecure client, and how the refresh should work.

Greetings Damien

[andifalk]

Hi @damienbod yes, storing of the tokens in the unsecure client is another problem that is currently discussed a lot. One solution discussed often here is here to store token inside a cookie (with httponly and secure flags set) plus adding CSRF protection.

[damienbod]

@andifalk Using cookies like this is not a better solution for SPAs, works good for server rendered Web application though.

[damienbod]

https://github.com/damienbod/angular-auth-oidc-client/pull/363

[damienbod]

@andifalk @b-wins @SaltyDH @ttothebrown

If the reviews are ok, I add this to the next version. See PR

[damienbod]

released in 9.0.0, would be grateful for feedback

Greetings Damien