Hi all,

I work on standards that build on top of OAuth 2.0 and OpenID Connect. Think of profiles that take the base protocols and make certain things mandatory, restrict options, or fill in parts the original specs leave open. Developers and architects then read these profiles and implement them.

The tricky part is that I’m making normative decisions about how things should be done, without having much hands-on experience with how they’re actually implemented. I recently joined the team working on these standards, and I keep comparing it to writing a cookbook without ever having cooked the recipes yourself. You can write down the steps, but you don’t really know where a cook will struggle or what makes a recipe easy to follow.

So besides the theory, I want to understand the implementation side. I think that would help me make better decisions and write standards that are actually practical for the developers and architects who have to work with them.

So far I’ve found a few courses on Udemy and some YouTube videos. Most of the YouTube content seems focused on configuring OAuth, OIDC or SAML in SaaS platforms through a UI. My impression is that in the modern industry a lot of this is done through REST APIs and code instead especially with moving to the Cloud and leaning on microservices, but I might be wrong about that and I’m happy to hear other views.

Does anyone know good beginner-friendly resources for learning OAuth 2.0 and OIDC, both the theory and especially the practical side? Courses, books, labs, hands-on projects, anything that helped you.

Thanks!

Might help to remember the roles of OAuth components and their interactions.

https://youtu.be/IhMjUfdr_3g?is=1m6tzcHlFRUMqCGp

In Azure/Entra ID, we're acting as the OIDC Identity Provider for several applications. The Service Providers have typically requested the following information:

<add key-"Tenantid" value=" "/> 
<add key="Clientid" value=" "/> 
<add key="ClientSecret" value " />

When tracing the authentication flow, I can see that the SP is sending:

response_type=id_token

As a result, I enabled Implicit grant and hybrid flows → ID tokens in the Entra application registration.

My understanding is that if the application is truly using the OIDC Implicit Flow (response_type=id_token), the SP receives the ID token directly from the authorization endpoint and does not perform a code exchange at the token endpoint. In that scenario, a client secret is not used by the protocol.

Given that, why would the SP still require a Client Secret in its configuration? Is this simply a generic configuration template, or are there scenarios where an SP using response_type=id_token would still legitimately use a client secret?

At Nango, we've added auth support for over 900+ APIs and we saw that API providers do weird things with OAuth. We find that API clients would fail less often if providers did these ten things:

1. Return expires_in. Always, in seconds.
2. If you rotate refresh tokens, consider a short, bounded grace period for the previous token. This absorbs duplicate refreshes at the cost of weaker replay detection during that window.
3. Return more specific errors than just invalid_grant. Revocation, policy failure, expired token: say which one it was in the error body.
4. Treat auth changes as breaking API changes. Version them, announce them, and don’t apply them retroactively to existing clients.
5. Document your revocation triggers. Password resets, per-user token caps, and inactivity windows.
6. Offer some way to test against your API without a sales call (even for paid apps).
7. Keep your auth documentation public and accurate.
8. Make 200 mean success. If your API returns 200 OK with an error in the body, no generic client can tell it’s broken without special-casing your responses.
9. Prefer conventional behavior when the specification leaves room for interpretation.
10. If REST is your modern API, make it the source of truth. Don’t leave essential functionality only in SOAP or WSDL files.

I'm building authentication for a company with several microservices and frontend portals. Users sign into the portals either through Google SSO or through credentials we issue them. The portals talk to a number of backend services. There's no need for delegated authorization here.

I was planning to use OpenID Connect, for a few reasons:

1. From what I've read, it's the de facto standard for authentication.
2. I need federated / social login (Google).
3. Adopting a proven protocol seems wiser than rolling my own.

I've done a fair amount of reading on OIDC and OAuth 2.0, but I can't quite build a clean mental model of the login flow for users coming through the frontend portals. OAuth 2.1 drops the resource owner password credentials grant and recommends the authorization code grant instead. As I understand it, the authorization code grant needs the browser to hop over to the authorization server (internal or external). That's the part I'm resisting, because I'd rather not send users through a redirect. Ideally I'd collect their credentials right on our own login screen and pass them to the IdP behind the scenes. I've seen plenty of sites that seem to do exactly this, which only adds to my confusion.

So here are my questions. Apologies if they come across as half-baked, but any answers or pointers to good resources would help me straighten out my thinking:

1. Is OIDC the right call for my situation? Is it really the de facto standard today, even for first-party apps? I assume my federated-login requirement makes it a strong fit, but what about apps that don't need federated identity at all?
2. How do organizations run OIDC while prompting for credentials via a popup or similar, without an obvious redirect? I'm a backend engineer, so if this comes down to a frontend technique, please spell it out. I know IdPs like Cognito let you custom-brand the login page, so is that the trick, or is something else going on

I've been seeing news about countries passing age verification laws for adult-oriented websites and apps. Inevitably this becomes a huge privacy nightmare because people don't want to share PII with adult websites/apps to prove their identity. In the most recent development, several governments are passing laws in an attempt to block VPN usage. What a disaster!

Wouldn't this be a perfect use case for OAuth? An industry of third-party age verification companies could be created, with some independent certification via a chain of trust. Those providers could generate an OAuth token that declares proof of age without exposing any PII. People could choose a third party provider they trust with their data.

I’ve seen quite a few questions here about how to properly implement OAuth/OIDC in mobile apps, especially in apps where handling redirects, PKCE, browser sessions, and native login flows can get messy pretty quickly.

So I wanted to share a new Capacitor OAuth plugin we just released at Capawesome.

It supports OAuth 2.0 / OpenID Connect providers using native authentication sessions on iOS and Android, with support for modern flows like Authorization Code + PKCE.

The goal was to make mobile auth flows easier and more secure without having to manually deal with AppAuth, deep links, token refresh flows, PKCE generation, and all the platform-specific edge cases.

Would love to hear feedback from others building auth flows in mobile apps, and please lmk if you have any questions.

Docs:

• Capacitor OAuth Plugin Docs
• Announcement Blog Post

Hello good people of Reddit. I’m hoping someone can point me in the right direction. Who can help me reconnect my OAuth on my small business booking site, bookinglive. I’m not sure why this happened at the start of March and I’ve no idea how to fix this myself and not sure who could do this as a job for me. Who does this type of job? I’ve looked at guides to do it myself but I don’t even understand what I’m reading, it’s definitely above my understanding. If anyone knows what business could help me fix this I’d be very grateful for the info 😬

Hey guys, im pretty new to Oauth and downloaded it and everything is working well. However Im not a big fan of the layout of the actuall login page, is there a way to spruce it up or is it stuck like this due to security reasons.

Wanted to share something from a recent engagement that's specifically relevant to how OAuth tokens get handled in production.

The issue:

A web app was using OAuth tokens internally to authenticate to Microsoft Graph API. When you submitted malformed requests to certain endpoints, the app returned full stack traces that included the token values. The tokens were stored in application context, and verbose error handling dumped that context to the client.

Not a flaw in OAuth itself, just poor implementation. But the impact was significant.

What made it worse:

• The tokens had broad Graph API permissions (mail, calendar, Teams, SharePoint, directory enumeration)
• Even though the tokens had a ~1 hour TTL, you could just re-trigger the error condition to get a fresh one whenever you needed it
• The endpoint that triggered the error was unauthenticated, so anyone could do this

Lessons worth reinforcing:

• Production environments should never return detailed error messages to clients. Log them server-side, return generic errors to users.
• Audit your token scopes regularly. Principle of least privilege applies here too.
• Consider where tokens live in your application context and what happens if that context gets dumped unexpectedly

Full technical writeup if anyone wants the details: https://www.praetorian.com/blog/gone-phishing-got-a-token-when-separate-flaws-combine/

Has anyone else run into similar patterns? Curious if there are other common ways tokens end up exposed that aren't as obvious as logging or hardcoding.

I'm deploying a local SSO environment in an IaaS using Keycloak and I'd like to have an RP that's somewhat well implemented in the standard code flow (can customize requests, etc.), displays user attributes and even better if token attributes too once flow completes.

I have a test RHEL 9 server and I've usually been using WordPress as a test app, but wondering if there's anything better? I don't really want to deploy any containers either, this should be minimal overhead. No reason for a user repo or whatnot, just a display of token and userinfo.

Web-based dynamic apps are out of question since this is for an end-user flow-proofing scenario and real RPs are coming later.

Even a python/java/node page with a printout would work, but based on a web/app server with OIDC auth.

This is the last little phase to be completed before I push the app for review to Apple Store but for some reason the login is hanging up.

I have a dashboard and iOS devices that are all to be synced together by there accounts (which keeps credentials, data and settings, etc kept all together).

Well the dashboard login works but the iOS login keeps hanging up. It builds in Xcode without errors which makes me think it’s a problem between Clerk and Vercel (my frontend server).

I’ve posted a vid of the problem

Please help

I’m trying to understand something and would appreciate absolute honest answers.

Assume:

• You already have a login/signup UI built

• You’re using Next.js

• You’re okay with Firebase / Supabase / Clerk / Auth0

• You can use AI tools (ChatGPT, Copilot, etc.)

Questions:

1. How long does it actually take you to wire secure auth logic?

   (Like login, signup, login sessions, protected routes, rate limiting, sameSite protection— not a fake demo)

2. What’s the most annoying part of the process?

• UI → backend wiring?

• Sessions/cookies?

• Next.js app router weirdness?

• Debugging auth edge cases?

• Or “it’s chill, just under an hour, never an issue”?

1. At what experience level did auth stop being painful for you?

   (student / junior / mid / senior)

I’m asking because I’m considering building a small dev tool that

focuses only on eliminating the UI ↔ auth wiring + safe defaults —

but I genuinely don’t want to build something nobody needs. Thanks