Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> I agree, I removed the mention of OIDC. If that means you'd leave the OAuth prohibition, it's still misleading or confusing. OIDC is of course an extension of or layer over OAuth. If you prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's the way it reads. On Thu, Jul

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I agree that there's a problem regarding the scope of this BCP . Or at least, I'm confused. Is this BCP supposed to be all about the architecture where the browser holds the token(s)? If so, then a) let's just put that out front and center: that's the context of this BCP. That's what's meant by

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

ven from the server-side piece of >> the application, as any other normal server-side client would. The result >> would then simply be a cookie-based authentication session in the client, >> and any JS code would leverage the http only, same-site cookie for Ajax >> ca

Re: [OAUTH-WG] Refresh tokens

I left out Okta (how could I?) - it supports a refresh token expiration, but I couldn't find doc on the details. On Sun, Jul 21, 2019 at 10:44 AM Brock Allen wrote: > > IdentityServer allows a choice of behavior on refresh token

[OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

The advice for the architectural pattern "JavaScript served from a common domain as the resource server" reads: "For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the domain of the API (resource server), it may be a better

Re: [OAUTH-WG] Refresh tokens

inking that our language might say that "if the OP supports refresh token (absolute) lifetime, refresh tokens may be used (in the browser), but should (must?) specify a expiration time." On Sat, Jul 20, 2019 at 2:54 PM David Waite wrote: > > > > On Jul 20, 2019, a

Re: [OAUTH-WG] Refresh tokens

steals >>> one and uses it, then the SPA will get an error on it's next attempt >>> because it's refresh_token will now be invalid. If the refresh_tokens are >>> bound to the user's authentication session, then the user can logout to >>> lockou

[OAUTH-WG] historical note regarding use of url fragment in OAuth for Browser-Based Apps draft -02

re: 9.8.7 . Historic Note Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without tri

[OAUTH-WG] Refresh tokens

Ok, I'm creating a new posting for this feedback. :) Here's where I probably just need some enlightenment, so please help me out. Re 8. Refresh Tokens "For public clients, the risk of a leaked refresh token is much greater than leaked access tokens, since an attacker can potentially con

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I see now that my arguments for softening the 6.1 language are backed and expanded on by the last paragraph of section 5, starting with " By redirecting to the authorization server,..." On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > regarding 6.1. Apps Served from a Common

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

tions where the same organization provides both the api and the application." On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > regarding 6.1. Apps Served from a Common Domain as the Resource Server > > Isn't this recommendation neglecting some benefits or use cases of

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

regarding 6.1. Apps Served from a Common Domain as the Resource Server Isn't this recommendation neglecting some benefits or use cases of Oauth? * An application that doesn't collect user credentials is an app that doesn't need to be audited for problems such as password leakage into log files.