What are /r/oauth's favorite Products & Services?

From 3.5 billion Reddit comments

This may help. It takes a broader approach but gets through the request_token also. https://fusionauth.io/learn/expert-advice/oauth/oauth-v1-signed-requests

Some sites are still using OAuth 1, but it's better to use a more recent approach. The FusionAuth software engineers may be able to help, but they have a few specific questions for you. Join us (free) Feb. 18 and ask! https://zoom.us/webinar/register/WN_aMqsrVKgRIm4rtZmvk7xQg

Firebase worked very well for me for some time, but then I had to move to NextJS and I started facing problems with the authentication to make server side rendered pages. It turns out that in the docs they kinda discourage use Firebase for anything other than static page generation. It also did not support a wide range of oAuth providers, tho workarounds are possible. There is a community package to use Firebase authentication with SSR, but I find it way too complicated to use and set up. https://nextjs.org/docs/authentication#firebase

Auth0 seems to work much better with NextJS Server Side Render, but then I had the problem of linking accounts. It actually provides an extension to do that, but the extension always prompt the users if they want to link the accounts, and this is not a behavior that I intend to have. I believe that this can be achieved tho, and this leads me to my second concern: Its way too disorganized. To do anything you need to go to the panel and edit a NodeJS code snippet that is not documented well, and you do not have a proper sandbox to at least test and debug the changes you are doing. And the third concern: Its limited to only two social logins per free app, and at the moment I cannot afford to paid plans for my projects that are not even profiting...

The fourth concern on Auth0 is that I could not customize the login/consent/linking accounts screens and keep them as files in the main project as part of the NextJS app, they need to be raw HTML files uploaded to the Auth0 panel. This is not good at all

That's the reason why I started ReAuth =)

I don't know if it necessarily violates the spec or not but it definitely mushes things in a way they weren't intended to be used. OAuth2 is an authorization/delegation framework that is intended to give explicitly consented access (and sometimes PARTIAL accees), on behalf of the resource's (usually an API) owner. OIDC is intended to give information about who the logged in user is. Access tokens are usually intended for use as authorization into an API whereas ID tokens are usually intended for introspection and use by the client itself.

It's also entirely possible that your system wants to give only delegation (OAuth2) or only user identification (OIDC) to a client, and not both. If you muddle everything into one place then you lose your ability to separate those concerns and provide access to one or the other per-client. To be more concrete, if a client does not have the `openid` scope assigned, they literally should NOT even be able to get an id_token at all (but they could still get an access_token).

Some other stuff:

• Both access tokens and id tokens can get quite large, depending on what you put into them. Separating out the id claims and data that does NOT need to be passed along further down the network is valuable.
• The way the `sub` claim in the access token and id token is populated are different and in some cases they may not be the same thing. Trusting the value in one token to mean the same as the other token type could be potentially dangerous and incorrect.

More here: https://auth0.com/docs/tokens

Your question boils down to the the security implication of holding an access token, and perhaps a refresh token, browser-side. As far as I can tell, from the study that I've done, is that it simply isn't as safe. While the safest browser-side option that will survive a refresh is session storage, that is vulnerable to XSS attacks, or use of compromised JS libraries, or the end-user's use of unsafe browser extensions. If you don't need to survive a refresh, you can just use DOM memory, perhaps further protected by use of Web Workers or JS closures. Oauth has a good article on these considerations.

Would love to see a lively conversation on this.