OAuth 2.0. No session? (stateless)

Question

I'm going to implement OAuth 2.0 and REST API with it

to grant different permissions per users and also to scale well.

To scale well, stateless is easier because there is

NO file, database, in-memory based session with it.

---

Below is how I understand OAuth 2.

1. OAuth Server give an access token to a user.
2. The user's access token is stored in cookie.
3. When user access to REST API, user sends with the access token.
4. Server receives request with access token.
5. Server find out whether access token is valid and the user has permission to do request.
6. Do or reject based on user's privilege.

---

So I do not have to worry about session storage. Right?

Hydromagnetics

Take a look at this library pypi.python.org/pypi/python-oauth2 – Roadrunner

I still think no one answered the exact question. By session storage, I am assuming inside a DB or Redis. So I am using Oauth 2.0 and I only need to store Refresh Tokens against the users in my DB. I am using the Implicit Grant Flow. Any suggestions or comments? – Jerilynjeritah

Answer 1

What you are describing here, is the OAuth 2 Implicit Grant flow. OAuth 2 also includes three other flows, but as it seems that your ressource owner (the user) is initiating requests using browser side Javascript (you were talking about cookies), this is the flow you should go for.

On client side, OAuth only requires you to store the access_token for accessing protected ressources (and a refresh_token if you're going for an expiring access_token).

Flynt

To check against access token he'll have to have a db server side. ;) – Promptbook

Sure, on server side he has to know for each access token on which user's behalf it was issued and which scopes were granted. Optionally he could also remember and check the allowed redirect_uri for better security. If that is what he meant with "session storage", I misunderstood the question ;) – Flynt

Forget the part about the redirect_uri, it's wrong. I should go to bed ;) – Flynt

Answer 2

A more recent innovation is JWT - JSON Web Token.

Here is a link to the spec: JWT - JSON Web Token

JWT is a method of using Hashed tokens using a Hashing method such as HMAC which stands for a Hash-based Message Authentication Code. Because the token is hashed using a secret key, the server can determine if the token has been tampered with.

Here is an example method to create a Hashed token for JWT:

    public String createTokenForUser(User user) {
        byte[] userBytes = toJSON(user);
        byte[] hash = createHmac(userBytes);
        final StringBuilder sb = new StringBuilder(170);
        sb.append(toBase64(userBytes));
        sb.append(SEPARATOR);
        sb.append(toBase64(hash));
        return sb.toString();
    }

Here is an example of decoding a token to ensure it was not tampered with:

public User parseUserFromToken(String token) {
    final String[] parts = token.split(SEPARATOR_SPLITTER);
    if (parts.length == 2 && parts[0].length() > 0 && parts[1].length() > 0) {
        try {
            final byte[] userBytes = fromBase64(parts[0]);
            final byte[] hash = fromBase64(parts[1]);

            boolean validHash = Arrays.equals(createHmac(userBytes), hash);
            if (validHash) {
                final User user = fromJSON(userBytes);
                if (new Date().getTime() < user.getExpires()) {
                    return user;
                }
            }
        } catch (IllegalArgumentException e) {
            //log tampering attempt here
        }
    }
    return null;
}

Here is an article with a more complete example: Stateless Authentication

Timid