Comment by taurath - Hacker Neue

taurath Jan 27, 2025 parent

If you implement it twice, the sequence diagram tends to get burned into the brain. It’s tricky and you’ll be able to anticipate its trickiness.

unshavedyak Jan 28, 2025

My problem is what part you're implementing can be different. Are you implementing the ability to use someone else as auth? Are you implementing the ability for others to use you as auth? Are you a client, or a server? etc

I don't know oauth at all, but that was the area that always felt convoluted when i'd research it. I think i'd be much happier if they had sub spec names with very specific use cases. OAuth2 Client Redirect, OAuth2 Server Authority, or w/e.. i'm just making stuff up for attempted clarity.

XorNot Jan 29, 2025

My problem is that my use case is always this: by default the application should be it's own OAuth server, so the endpoints can use OAuth against the application and a local only database.

Then I want an easy story for linking that instead to LDAP for corporate deployments, or to an SSO OAuth server.

The problem is...well I still don't really know how I should be including that? It's so much easier just to register a session cookie from a login page.

jpc0 Jan 29, 2025

> The problem is...well I still don't really know how I should be including that? It's so much easier just to register a session cookie from a login page.

For a webpage this makes perfect sense, where would you securely store an access / refresh token on web that isn't vulnerable to XSS? In a session cookie that is secure & http only...

For native apps though that state might be more annoying to track and a auth token and refresh token is pretty easy to store securely.

This item has no comments currently.

Preferences

Keyboard Shortcuts

Story Lists

Navigation

Miscellaneous