Menu
The other minute I read an article on OAuth. It described especially the tokens being exchanged between client and service provider during a series of requests.
The article also mentioned that OAuth gains significant popularity in RESTful APIs as authorization layer. As I understood, REST should be kept completely stateless.
The question: Doesn't this repeated token exchange torpedo REST's "being stateless" principle? IMHO the tokens can be seen as a kind of session ID, can't they?
902
The main difference is session-based authentication of the connection stores the authentication details. The session method makes the server store most of the details, while in the case of the token-based one the client stores them.
Tokens and sessions essentially are about where the authorization state is handled, whether on the server-side or the client-side. For example, a server can issue a JWT token via cookie, or expect a stateful session ID to be provided in the “Authorization” header.
The difference between a refresh token and an access token is the audience: the refresh token only goes back to the authorization server, the access token goes to the (RS) resource server. Also, just getting an access token doesn't mean the user's logged in.
RESTful API endpoints should always maintain a stateless session state, meaning everything about the session must be held at the client. Each request from the client must contain all the necessary information for the server to understand the request.
OAuth tokens are explicitly a session identifier, interaction is not stateless between requests in the OAuth token negotiation protocol as the requests must be performed in a specific sequence, and they do require per-client storage on the server as you need to track things like when they were issued. So yes, OAuth does violate the strict principles of a RESTful architecture.
Unfortunately there's the Real WorldTM to contend with where we need to do things like allow applications to authenticate on the behalf of individuals without requesting their password, which OAuth does fairly well. It would be impossible to implement a similarly secure authentication scheme without this kind of state. Indeed, one of the changes required by OAuth (1.0a) was to add more state to the token negotiation protocol to mitigate a security risk.
So, does it torpedo REST's stateless principle? Yes. Does that matter? Not unless you live in an ivory tower :-)
108
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
