2 ms·
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
by unshavedyak 2y ago
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.
- deleted 2y ago[deleted]
- XorNot 2y agoMy 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 2y ago> 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.