Rest – Enterprise patterns for JWT authentication for REST-based application

architectural-patternsauthenticationrest

The JWT specification describes only the payload and how it is sent, but leaves authentication protocol open, which allows the flexibility, but quite unfortunately, flexibility can lead to antipatterns and misdesign.

I'm looking for some well thought and tested enterprise patter for JWT authentication, which I could use or adapt, but I've failed to find something complete.

What I was thinking of is:

when no Authorization header is met, or the JWT token is invalid, or expired, send HTTP 401
in order to authenticate, use /login REST channel, send username and password as JSON object
in order to keep token alive, use /keepalive REST channel, call it every N (5) minutes, receive new JWT token and replace the existing one after each call (the token expires after M (15) minutes)

However, what disturbs me, is the necessity of that /keepalive channel. On the other hand, it forces me to prevent the authentication to expire, even if the user is away (the decision, if we would want keepalive is not yet met) and of course, those are extra calls and extra complication to protocol. What would be interesting, is that server automatically prolongs the token. In session-based environment it happens by resetting the timestamp, here, however, the server would have to sent new token, maybe not each time, but once the token is going to expire in R (say, 10) minutes. But placing it in response body would mean to modify the JSON response protocol (therefore, the solution is invasive and not transparent), and putting an extra HTTP header that client could process could not necessarily be a good pattern. I'd think about just placing Authentication Bearer xxxTOKENxxx header in Response if I'd have to choose…

Are there any ready enterprise patterns which answers my open points? Is my protocol draft a reliable idea? I'd prefer to use something ready than design from scratch.

Best Answer

JWT (Intro to JSON Web Token) is just a token format, authentication it's something completely out of scope for that specification. It is indeed commonly used within authentication systems, but you could also use it for completely different scenarios so it makes sense to not include authentication specific constraints within that specification.

If you're looking for guidance on authentication you should refer to the OpenID Connect family of specifications. Additionally, if your system is comprised of HTTP API's and you're interested in providing delegated access to those API to your own or to third-party client application then you should refer to the OAuth 2.0 specification.

There are additional authentication related protocols like SAML and WS-Federation that are still widely used in enterprise scenarios, but they are significantly more complex to implement.

About your specific open points:

The bearer token authentication scheme is defined in RFC 6750 which contains instructions on how to perform requests and the possible error codes.
OAuth2 and OpenID Connect both contemplate the possibility and define the way to exchange a username/password with a token.
The problem of extending a self-contained/by-value token (JWT) lifetime is addressed within OpenID Connect and OAuth2 through the means of refresh tokens.

Even though OAuth2 and OpenID Connect can be seen as easier to implement than some of its predecessors, they are still complex enough to warrant some caution and only implement them yourself if you're willing to spend a considerable amount of time and resources. It's generally a better option to use third-party libraries or services that do that heavy-lifting for you.

Finally, these protocols cover a lot of scenarios so they may be overkill in some situations.

Related Solutions

Rest – Designing authentication for REST API

Rather than invent your own, you should consider reading the OpenAM API and borrowing it.

http://forgerock.com/openam.html

The OpenAM Wiki is particularly helpful

https://wikis.forgerock.org/confluence/display/openam/Home

You don't need to use their components. But if you use their API, you'll find that your life will be simpler in the long run.

REST Service Authentication/Authorization

If you are looking for ideas about security for REST web services then look at the OpenAuth spec Appendices describing the "handshake".

http://oauth.net/core/1.0/#anchor27

Creating web services that adhere to OpenAuth standards is probably one of the more secure ways that this can be done. It can give you ideas on authentication, authorization strategies.

The following is an example taken from the Authorization header in a GET or POST:

Authorization: OAuth
    oauth_consumer_key="xxxxxxxxxxxx",
    oauth_token="xxxxxxxxxxxx",
    oauth_nonce="xxxxxxxxxxxx",
    oauth_timestamp="1184242096",
    oauth_signature_method="HMAC-SHA1",
    oauth_version="1.0",
    oauth_signature="xxxxxxxxxxxxxxxxxx"

I am not going to go into all the details of OpenAuth but essentially it allows a client to provide a consumer key that identifies the client, a token that identifies the user, and a signature that represents the Base64 encoded bytes of the encrypted signature to verify that the request has not been tampered or altered on transport.

Building the signature string typically involves the percent encoded combination of the entire request, parameters, as well as consumer key, token, nonce, and a consumer secret which the client should keep safe. Once this signature string has been built and percent encoded it can then by encrypted, and those encrypted bytes can be constructed into a Base64 encoded string that is included in the Authorization header.

If you perform this over SSL, then this is undoubtedly one of the most secure ways to handle authentication/authorization of a REST based web service.

Best Answer

Related Solutions

Rest – Designing authentication for REST API

REST Service Authentication/Authorization

Related Topic