very comprehensive but i wanted to add. oauth is one of those things i read about and forget 6 months later. there has to be a gamified way to make people learn about oauth and enforce it deep inside their brains
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.
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.
> 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.
As with everything: repetition. If you forget these things you don't use them often enough. On that level, do you really need to remember them or are you happy enough to have a good and short reference, like this article for example?
