4 ms·

Am I the only one who thinks Oath is over-complicated bordering to security through obscurity and vendor lock-in ? The protocol could be as simple as this (usi

by z3t4 5y ago

Am I the only one who thinks Oath is over-complicated bordering to security through obscurity and vendor lock-in ? The protocol could be as simple as this (using password) app => auth-server (can user:pass login to app?) auth-server => app (no | yes) Or using "crypto": app => auth-server (can user login to app ?) auth-server => app (only if user can solve challange=XXXX with answer=YYYY) Asking for capabilities: app => auth-server (what permissions do user have on app ?) auth-server => app (user has access to: X, Y, Z)

paisawalla 5y ago
First scenario: user's password can be captured and stored by the app. Second scenario: could work if we're talking about a trusted third party app (e.g. Authy) generating the response. Otherwise presumably you enter your secret into the app, where the OTP is derived. This has the same problem as above. Third scenario: no authentication required to query for capabilities? Puts on black hat Ok let me quickly check [A-Z]{1,18}@whitehouse.gov and see which accounts I'm most interested in.
mooreds 5y ago
Sure, if all you need to know is "can this user login" and you don't have multiple servers that want to authorize the user, you probably don't need OAuth. You can use sessions and cookies. See my comment elsewhere in this post about this: https://news.ycombinator.com/item?id=31007003 https://news.ycombinator.com/item?id=31007003 Interestingly, your first scenario is the resource owner password credentials grant: https://datatracker.ietf.org/doc/html/rfc6749#section-4.3 https://datatracker.ietf.org/doc/html/rfc6749#section-4.3 The second scenario is, I believe, the JWT bearer grant: https://www.rfc-editor.org/rfc/rfc7523 https://www.rfc-editor.org/rfc/rfc7523 Of course in the OAuth grants, the auth-server returns a token to be presented to other resources instead of a "yes" or "no" answer.

by z3t4 5y ago

paisawalla 5y ago

First scenario: user's password can be captured and stored by the app. Second scenario: could work if we're talking about a trusted third party app (e.g. Authy) generating the response. Otherwise presumably you enter your secret into the app, where the OTP is derived. This has the same problem as above. Third scenario: no authentication required to query for capabilities? Puts on black hat Ok let me quickly check [A-Z]{1,18}@whitehouse.gov and see which accounts I'm most interested in.

mooreds 5y ago

Sure, if all you need to know is "can this user login" and you don't have multiple servers that want to authorize the user, you probably don't need OAuth. You can use sessions and cookies. See my comment elsewhere in this post about this: https://news.ycombinator.com/item?id=31007003 https://news.ycombinator.com/item?id=31007003 Interestingly, your first scenario is the resource owner password credentials grant: https://datatracker.ietf.org/doc/html/rfc6749#section-4.3 https://datatracker.ietf.org/doc/html/rfc6749#section-4.3 The second scenario is, I believe, the JWT bearer grant: https://www.rfc-editor.org/rfc/rfc7523 https://www.rfc-editor.org/rfc/rfc7523 Of course in the OAuth grants, the auth-server returns a token to be presented to other resources instead of a "yes" or "no" answer.