Is it possible to use this app for Web Application?

[cstpraveen]

I am using react SPA. Will it possible to use auth code flow in the web application?

All the documentation mentioned like this library is for Native applications.

Will it possible to use this app in Web App (Browser based application).

[brockallen]

For SPAs you want a library built for those scenarios. Consider oidc-client: https://github.com/IdentityModel/oidc-client-js/. It's OIDC Certified: https://openid.net/certification/#RPs

[tikurahul]

Yes, you can use the code flow in a web app.

Here is an example that does that: https://github.com/openid/AppAuth-JS/tree/master/app The TS source is here: https://github.com/openid/AppAuth-JS/blob/master/src/app/index.ts

In fact, the example is a React app.

[brockallen]

Hmm, I find it odd that you'd mark my comment as outdated. I was just trying to help the OP given that I was under the assumption that this library was only geared for code flow with PKCE. Does this library support implicit as well?

[tikurahul]

Sorry, but I thought your commend did not reflect the best answer. That's why I marked it as out of date.

We don't support implicit mode because it goes against best practices. However, there are examples that use AppAuth-JS that use implicit mode. This library does not intend to be a one size fits all OAuth2 library. It follows what the best practices are.

[brockallen]

It follows what the best practices are.

Not to be a jerk about this, but there are no such things as "best practices". "Best practices" have context. So this library shows the best current thinking for native/mobile apps (specifically RFC8252: https://tools.ietf.org/html/rfc8252), and that's using authorization code flow using a system browser with PKCE. But the OP's question was about a different context, specifically browser-based client-side JS apps (also known as SPAs), which is not the context this library is addressing.

That's why I provided the answer I did, as it's implementing the "best practice" for SPAs. My intent was not to reduce or minimize the value of this library, and in fact as people ask for doing native apps in my issue tracker I often point them here as the right way to be building those apps.

Sorry, but I thought your commend did not reflect the best answer. That's why I marked it as out of date. We don't support implicit mode because it goes against best practices.

Can you point me to the OAuth2 RFC (https://tools.ietf.org/wg/oauth/) or OIDC specs (https://openid.net/connect/) that give this guidance for implicit flow?

[tikurahul]

Yes, I was referring to the RFC8252: https://tools.ietf.org/html/rfc8252.

While you are correct in pointing out that these best practices apply to native and mobile apps, our experience with OAuth2 at Google has taught us that implicit flow for a web app is something you almost never want. implicit flow forces the user to change context, and look at a permissions prompt. This places a burden on the user. While there are ways to make this experience better (prompt=none, storing encrypted things your server can trust in local or session storage) but they are either non standard, or hard to get right. Also, the interaction between the user session with the IDP and the app using the implicit flow is also something the end user may not understand. For e.g should an app using Google Sign in implicit mode log a user out when he logs out of Google ? Does it make sense to the user ?

I hope this provides the context you need. We have had many conversations about implicit flow before (if you look at past issues) where we have discussed and arrived at the same conclusion.

[brockallen]

our experience with OAuth2 at Google has taught us that implicit flow for a web app is something you almost never want

Do you mean client-side or server-side?

implicit flow forces the user to change context, and look at a permissions prompt. This places a burden on the user

Can you elaborate?

[tikurahul]

Just updated my comments. I am going to stop discussing this further - because we not discussing what the OP asked. 😃

[brockallen]

Just updated my comments.

I still can't tell from what you updated. And from the little bit I could follow, I don't see how authorization code flow solves the issues you raise.

I suspect much of the thinking comes from google as an IdP perspective, rather than from apps in general that need/want to use OIDC/OAuth2 (and that don't even use social IdPs).

I am going to stop discussing this further - because we not discussing what the OP asked.

But this is exactly what the OP needs, and apparently me as well since the spec committees don't have the guidance you claim to have. At least provide a link to an article explaining why implicit for client-side JS apps is no longer valid guidance, and now why code flow is legit for those types of apps?

Also, the OP might find it interesting :)

[brockallen]

I tried to find the issues in this repo you referred to and also found links out to a couple of posts claiming that code flow is now the latest recommendation. I'm a bit hesitant to outright trust the one blog post I see on this, but given that it now seems to be google's official stance, then I dug into it some more.

From what I can tell from my research, the complaints with implicit are:

• access token in URL
• access token in browser history
• iframe complexity when using prompt=none to "refresh" access tokens

But this requires:

• AS/OP to support PKCE
• AS/OP to support CORS
• user-agent must support CORS
• AS/OP to maintain short-lived refresh tokens
• AS/OP must aggressively revoke refresh tokens at user signout (which is not something OAuth2 "knows" about)
• if the above point can't work, then client must proactively use revocation endpoint if/when user triggers logout

From the above list of pros and cons, I think almost all of the issues are really just a matter of "where do you want to put the code to address the issues". Assuming there are either settings in an AS/OP, or libraries on the client to address all of those, then I think it's a wash. The only item in the above list that really resonates with me as a real security concern is the access token in the URL. That is sufficiently sensitive and easier to mess up, I concede that code flow with PKCE very much addresses that concern.

Having said that, it would still be nice of the OAuth2 working group did something officially to make this recommendation.

Additional complaints mentioned above were:

• implicit flow forces the user to change context, and look at a permissions prompt. This places a burden on the user.

I don't understand this one, because consent is consent regardless of flow, and it'ps even unnecessary for first-party clients. So I'm still unsure how this one relates. If the user chooses "remember my decision" then consent should not interrupt or confuse the user again.

• While there are ways to make this experience better (prompt=none, storing encrypted things your server can trust in local or session storage) but they are either non standard, or hard to get right.

So while I agree an Ajax call is easier than an iframe in terms of the code/logic/effort, the implicit guidance was written at a time before CORS could be taken as a dependency. Given that most people no longer need to support IE9 (although I still have many customers that do), then I concede that if the spec were rewritten today then a different approach would be taken.

• Also, the interaction between the user session with the IDP and the app using the implicit flow is also something the end user may not understand. For e.g should an app using Google Sign in implicit mode log a user out when he logs out of Google ? Does it make sense to the user ?

Google is the only IdP I've ever seen that have dealt dealt with the complexity to support simultaneous user sessions at the IdP. Kudos on that, but most other IdPs and non-social/enterprise scenarios where companies use their own internal IdPs, that's a strange concept and a moot point. I think that push-back, as of today, is a google-only concern. This library is being used beyond that context.

I know you said you don't wish to follow up on this here, so I'm happy to continue this discussion elsewhere. Feel free to move any of thread elsewhere.

[tikurahul]

Treating this issue as closed unless @cstpraveen needs further direction.

[joaco-espinosa]

@tikurahul If using authorization code (without client secret) + PKCE is the way to go:

1. How do you refresh tokens?
2. Do you allow public clients getting ahold of long-lived tokens (i.e. refresh tokens)?

[afsanefdaa]

I also need an example in react + web applications. Do you have any resources to refer to? thanks