Timeline for OAuth2 ROPC vs Basic Auth for public REST APIs?
Current License: CC BY-SA 3.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 14, 2019 at 6:24 | comment | added | Arun Avanathan | My use case is exactly similar to what @smeeb described above. User is not directly interacting with my API. User uses client application and client wants to use our service to serve its customers. This user is not a direct user of my APIs. For eg. - S3 is my service. My customer (client) uses S3 to store their customer (user)'s data. User doesn't have any relation with S3. In fact, he doesn't even know client uses S3 under the hood. Now, how could we use OAuth for client to talk to S3? | |
| Oct 13, 2015 at 8:17 | vote | accept | smeeb | ||
| S Sep 26, 2015 at 3:09 | history | bounty ended | CommunityBot | ||
| S Sep 26, 2015 at 3:09 | history | notice removed | CommunityBot | ||
| Sep 24, 2015 at 20:38 | history | unprotected | yannis | ||
| Sep 24, 2015 at 19:50 | history | protected | gnat | ||
| Sep 24, 2015 at 6:26 | answer | added | MvdD | timeline score: 3 | |
| Sep 23, 2015 at 6:24 | answer | added | Omer Iqbal | timeline score: 31 | |
| Sep 22, 2015 at 21:52 | comment | added | Omer Iqbal | @smeeb, I think I can write up an answer to your question tonight. One last clarifying question: you will always have a user (i.e. Resource Owner in OAUTH terminology) that is accessing the Rest API (i.e. the Resource). Is that correct? Or are you looking to authenticate the client without regard to the user? | |
| Sep 22, 2015 at 21:39 | history | tweeted | twitter.com/#!/StackProgrammer/status/646438737250004992 | ||
| Sep 22, 2015 at 21:02 | comment | added | Richard Tingle | Also I was under the impression that in ROPC the username/password where sent as form parameters rather than url parameters (not that that effects the security - other than accidentally logging them) (oauthlib.readthedocs.org/en/latest/oauth2/grants/password.html) | |
| Sep 22, 2015 at 20:57 | comment | added | Richard Tingle | I don't understand your point about base64 encoding, that's not a security feature (you can easily decode). I think it's more about character safety and such. But you're right ROCP is considered OAUTHS weakest flow (although I'd say it's equally as secure as what you have now). OAUTH2 requires https so you are relying on that to secure your communication (which is actually a good idea, https comes as standard, try to role your own secure pipeline (such as in OAUTHS alternative SAML) and you can so easily get it wrong | |
| S Sep 22, 2015 at 20:02 | history | suggested | Guanxi | CC BY-SA 3.0 | Fixed contents |
| Sep 22, 2015 at 19:34 | comment | added | smeeb | Thanks @OmerIqbal (+1). I'm building the API (REST service), but will leave client-side implementation up to each user. Therefore this solution must work with any (native, mobile, desktop, command-line, backend server, etc.) computer process that has the ability to communicate over HTTP. | |
| Sep 22, 2015 at 19:27 | answer | added | Guanxi | timeline score: 0 | |
| Sep 22, 2015 at 19:15 | review | Suggested edits | |||
| S Sep 22, 2015 at 20:02 | |||||
| Sep 22, 2015 at 3:43 | answer | added | Patrick | timeline score: 3 | |
| Sep 21, 2015 at 23:19 | answer | added | imel96 | timeline score: 1 | |
| Sep 21, 2015 at 18:12 | comment | added | Omer Iqbal | @smeeb I believe by client, the question is whether it is going to be a native client (i.e. IOS, Android, Windows, etc.) or a web client. In your question you imply it's not a web client, but clarification will be helpful. In OAuth2, that matters in determining which flow to use. | |
| Sep 18, 2015 at 13:08 | comment | added | smeeb | But, I should note, there are plenty of other use cases outside a command line/shell. Another use case is a Java/Ruby/Python pure REST/HTTP client that has no UI and might be running on a backend server that has no UI. The backend server needs to communicate with another backend server over REST. Here, not only would it be awkward and hacky to pop a UI when backend server #1 needs to speak to backend server #2, the real problem there is there's no browser/UI client to display the login page to, and there's no human being there to log in!!! | |
| Sep 18, 2015 at 13:04 | comment | added | smeeb | @decyclone no a pure REST client has no UI whatsoever, although UI's typically use a pure REST client for connecting to a REST service. One use case is a command line tool that uses a REST client for sending user commands (entered on the shell) to the REST service. Popping a UI from a shell just isn't an acceptable solution here. | |
| Sep 18, 2015 at 13:00 | comment | added | decyclone | The question I am asking is if that client has any UI at all? Even if it had not, I have seen applications with no UI pop a dialog at least for authentication. | |
| Sep 18, 2015 at 10:09 | comment | added | smeeb | @decyclone please read the very first sentence to the question! I'm taking about REST (headless HTTP) clients authenticating against REST services. | |
| Sep 18, 2015 at 5:07 | comment | added | decyclone | What kind of client are you talking about? I assume that most of the clients will have a UI. In which case, you can load up the OAuth login page in a webview (desktop, mobile) or redirect to it directly (web). I don't see why you need to avoid UI. | |
| S Sep 18, 2015 at 1:41 | history | bounty started | smeeb | ||
| S Sep 18, 2015 at 1:41 | history | notice added | smeeb | Authoritative reference needed | |
| Sep 16, 2015 at 10:30 | history | edited | smeeb | CC BY-SA 3.0 | added 1339 characters in body |
| Sep 16, 2015 at 1:09 | history | asked | smeeb | CC BY-SA 3.0 |