I’m all for using established solutions and not re-inventing the wheel, but I think it’s solving a different problem than OAuth set out to. What if I want to write a REST API to be used by untrusted clients? I’m not shoving a secret into my client side JS app.
Also last I checked Basic Auth has no good standard way to un-authenticate.
What do you mean by “unauthenticate”? I am under the impression that you have to pass the credentials with every request. Or are you talking about how browsers cache the credentials for you?
I agree. Though, do browsers cache basic auth credentials when making API calls from JavaScript? If not, I feel like this is not a general issue, but a UX one.
Basic Auth lacks a time nounce to prevent replay attacks, but the alternative is not OAuth which is more complicated as the problem it solves is Aut{oriz,henticat}ing I’m user A in C to B without sharing credentials
I’m reading this on the same day I’m implementing JWT (json web tokens.) It is, perhaps the happy medium between the two. For my scenario I’m using it for both a browser based implementation and an api. Because this is my first attempt at implementing such a thing I’m not sure what to expect. It seems reasonable in concept… I knew I wasn’t going down the oauth path before I started this implementation.
I’m all for using established solutions and not re-inventing the wheel, but I think it’s solving a different problem than OAuth set out to. What if I want to write a REST API to be used by untrusted clients? I’m not shoving a secret into my client side JS app.
Also last I checked Basic Auth has no good standard way to un-authenticate.
Completely true, but - imo - oauth shouldn’t be considered the default for api authentication.
You’re fully right about unauthenticating; only way known to me is the hackish unauthentication with wrong credentials.
What do you mean by “unauthenticate”? I am under the impression that you have to pass the credentials with every request. Or are you talking about how browsers cache the credentials for you?
The latter; since it’s basically a stateless affair; should’ve been more clear on this.
Would be nice if browsers would offer a built in logout button.
I agree. Though, do browsers cache basic auth credentials when making API calls from JavaScript? If not, I feel like this is not a general issue, but a UX one.
Afaik it is purely a ux issue: js initiated requests require the authorization header on every request.
You don’t have to shove your secret in the client side, but you could shove your public key.
Basic Auth lacks a time nounce to prevent replay attacks, but the alternative is not OAuth which is more complicated as the problem it solves is Aut{oriz,henticat}ing I’m user A in C to B without sharing credentials
Other than not being standardized, is there something that prevents an API from requiring an extra nonce header?
On the weekend I’m often seen driving around in my Oriz Henticat, it’s a V8.
No comparison to whatever the term is for “put API token in request params”?
This works with even more http clients. A quick search for “jquery basic auth” is kind of terrifying.
rfc6750 calls them “bearer auth tokens”, and provides for use in a header, form field, or query param.
I’m reading this on the same day I’m implementing JWT (json web tokens.) It is, perhaps the happy medium between the two. For my scenario I’m using it for both a browser based implementation and an api. Because this is my first attempt at implementing such a thing I’m not sure what to expect. It seems reasonable in concept… I knew I wasn’t going down the oauth path before I started this implementation.