top | item 42862567

(no title)

vmaurin | 1 year ago

Yes they are!

I think I know the reason: OAuth2 naming. In the OAuth rfc https://www.rfc-editor.org/rfc/rfc6749 they named one of the role "client", but than meant to represent a server in the more standard flow, while they named the browser "user-agent". Then people understood that "client" is the browser, so they went nuts storing access token and refresh token in the browser local storage, instead of being store in the server session storage, accessible with a session cookie.

So what people should have done https://www.rfc-editor.org/rfc/rfc6749#section-4.1 (you can see here the tokens never reach the user agent, so the server can keep them in a session, then have the user agent identified by a cookie. And what most of the people did https://www.rfc-editor.org/rfc/rfc6749#section-4.2

discuss

order

sam_lowry_|1 year ago

This is a very useful piece of information.

According to the saying "There are two hard problems in Computer Science: naming things and cache invalidation"...

OAuth 2.0 editors failed to properly name things.

mariusor|1 year ago

But there are many times when the client _is_ the browser. Are you sure you're not confused by that?

vmaurin|1 year ago

In the RFC, the browser is named "user-agent". And in OAuth2 flow, the browser is acting as client only on the implicit flow. Also the intent of the authors for the implicit flow is that the "client" is a mobile/desktop applications, and not especially something running in a browser