4 ms·

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

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

7bit 2y ago
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? My personal answer is: a cheat sheet is enough.
taurath 2y ago
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 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 ago
    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 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.
TrnsltLife 2y ago
I work on it every day and can barely remember...

7bit 2y ago

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? My personal answer is: a cheat sheet is enough.

taurath 2y ago

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 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 ago
  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 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.

TrnsltLife 2y ago

I work on it every day and can barely remember...