3 ms·

I can only give my perspective, which is likely to be unique. I'm in the process of implementing an Oauth2 server for the first time. I feel like I have a handl

I can only give my perspective, which is likely to be unique. I'm in the process of implementing an Oauth2 server for the first time. I feel like I have a handle on it now, but it was definitely overwhelming at first. If I were confident that RFC6749 had everything in it that I needed, I would read through and implement it. But it quickly became apparent that there are a dizzying array of RFCs with extensions, deletions, and best practices. So I just skipped the specs, and have been using resources like this, Oauth2 Simplified, and of course YouTube. So I guess the upshot is I find resources like this and the upcoming 2.1 to be valuable.

mooreds 6y ago
2.1 will hopefully be a one stop shop for implementors. At least, when I was writing a post about OAuth 2.1, that was the intention of the authors, from what I read on the mailing list.
vwpolo3 6y ago
Don't implement your own, there's tons of open source that can do that, for example https://github.com/ory/hydra https://github.com/ory/hydra
- anderspitman 6y ago
  Thanks for the link. I'm rolling my own for a reason. I'm working on not only an Oauth2 implementation, but also a specification for using Oauth2 for filesystem operations (btw if you're aware of such a thing existing already, I'd love to hear about it). So I need to be intimately familiar with Oauth2. I wasn't originally planning to use it, but ultimately it's close enough to what I need, and for better or worse users are familiar with the flows.
  - dwaite 6y ago
    > btw if you're aware of such a thing existing already, I'd love to hear about it Since OAuth is pretty coarse-grained, you tend to have: - A client has a policy configured for the file sharing service or file collection, and does not use e.g. the scope parameter to request particular permissions - A file collection lets scopes be assigned particular permissions, and a client requests access by requesting one or more scopes Although I am not a fan of the level of complexity it adds, UMA (User Managed Access) makes a pretty strong attempt at solving these sorts of problems as well.
    - anderspitman 6y ago
      But why do they have to be coarse-grained? If you have a cloud storage provider, why not allow scopes to be set per path, like this: scope="/dir1:read /dir2:write /dir3/file.txt:read" Then when the authorization screen is presented, the user could even modify the permissions granted on the fly. Usually applications only need a single directory to store data, and it shouldn't matter to the app where that directory is in relation to the rest of the user's data. In that case you could do something like this: scope="dir?:write" Which tells the authorization server to present the user with a directory picker, so the user has control over where the data is stored. It doesn't make any sense to give write permissions to all your data for every single application. After 5 minutes of poking around, I still don't understand how exactly UMA works in relation to Oauth2. I agree it seems to be pretty complex.

mooreds 6y ago

2.1 will hopefully be a one stop shop for implementors. At least, when I was writing a post about OAuth 2.1, that was the intention of the authors, from what I read on the mailing list.

vwpolo3 6y ago

Don't implement your own, there's tons of open source that can do that, for example https://github.com/ory/hydra https://github.com/ory/hydra

anderspitman 6y ago
Thanks for the link. I'm rolling my own for a reason. I'm working on not only an Oauth2 implementation, but also a specification for using Oauth2 for filesystem operations (btw if you're aware of such a thing existing already, I'd love to hear about it). So I need to be intimately familiar with Oauth2. I wasn't originally planning to use it, but ultimately it's close enough to what I need, and for better or worse users are familiar with the flows.
- dwaite 6y ago
  > btw if you're aware of such a thing existing already, I'd love to hear about it Since OAuth is pretty coarse-grained, you tend to have: - A client has a policy configured for the file sharing service or file collection, and does not use e.g. the scope parameter to request particular permissions - A file collection lets scopes be assigned particular permissions, and a client requests access by requesting one or more scopes Although I am not a fan of the level of complexity it adds, UMA (User Managed Access) makes a pretty strong attempt at solving these sorts of problems as well.
  - anderspitman 6y ago
    But why do they have to be coarse-grained? If you have a cloud storage provider, why not allow scopes to be set per path, like this: scope="/dir1:read /dir2:write /dir3/file.txt:read" Then when the authorization screen is presented, the user could even modify the permissions granted on the fly. Usually applications only need a single directory to store data, and it shouldn't matter to the app where that directory is in relation to the rest of the user's data. In that case you could do something like this: scope="dir?:write" Which tells the authorization server to present the user with a directory picker, so the user has control over where the data is stored. It doesn't make any sense to give write permissions to all your data for every single application. After 5 minutes of poking around, I still don't understand how exactly UMA works in relation to Oauth2. I agree it seems to be pretty complex.