Some words about authentication with tokens
Once you are using JAX-RS, have a look at this answer that I wrote a while ago.
Your tokens can be any randon string persisted to some storage. On the other hand, JWT tokens allow you to have stateless authentication (no persistence). If you need to track the JWT tokens (to revoke them, for example), you must persist at least their identifier (the jti claim). A HashMap shouldn't be used to "persist" tokens (that's not a real persistence and it won't scale). Instead, consider a database like Redis.
To generate and parse JWT tokens, have a look this library created by Stormpath and maintained by a community of contributors. I currently use it in some applications and I can say with confidence that it works just fine and it's easy to use.
Keep reading for more details about the authentication process.
Authentication with tokens at a glance
In a few words, a token-based authentication follow these steps:
- The client sends their credentials (username and password) to the server.
- The server authenticates the credentials and generates a token.
- The server stores the previously generated token in some storage along with the user identifier and an expiration date.
- The server sends the generated token to the client.
- In every request, the client sends the token to the server.
- The server, in each request, extracts the token from the incoming request. With the token, the server looks up the user details to perform authentication and authorization.
- If the token is valid, the server accepts the request.
- If the token is invalid, the server refuses the request.
- The server can provide an endpoint to refresh tokens.
Using JAX-RS to implement authentication based on tokens
The authentication starts when the server receives the hard credentials (username and password) of a user and exchanges them with a token that the client must send in each request:
@Path("/authentication")
public class AuthenticationResource {
@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public Response authenticateUser(Credentials credentials) {
try {
// Authenticate the user using the credentials provided
String username = credentials.getUsername();
String password = credentials.getPassword();
authenticate(username, password);
// Issue a token for the user
String token = issueToken(username);
// Return the token on the response
return Response.ok(token).build();
} catch (Exception e) {
return Response.status(Response.Status.UNAUTHORIZED).build();
}
}
private void authenticate(String username, String password) throws Exception {
// Authenticate against a database, LDAP, file or whatever
// Throw an Exception if the credentials are invalid
}
private String issueToken(String username) {
// Issue a token (can be a random String persisted to a database or a JWT token)
// The issued token must be associated to a user
// Return the issued token
}
}
A filter will be used to extract the token from the HTTP request and validate it:
@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthenticationFilter implements ContainerRequestFilter {
@Override
public void filter(ContainerRequestContext requestContext) throws IOException {
// Get the HTTP Authorization header from the request
String authorizationHeader =
requestContext.getHeaderString(HttpHeaders.AUTHORIZATION);
// Check if the HTTP Authorization header is present and formatted correctly
if (authorizationHeader == null || !authorizationHeader.startsWith("Bearer ")) {
throw new NotAuthorizedException("Authorization header must be provided");
}
// Extract the token from the HTTP Authorization header
String token = authorizationHeader.substring("Bearer".length()).trim();
try {
// Validate the token
validateToken(token);
} catch (Exception e) {
requestContext.abortWith(
Response.status(Response.Status.UNAUTHORIZED).build());
}
}
private void validateToken(String token) throws Exception {
// Check if it was issued by the server and if it's not expired
// Throw an Exception if the token is invalid
}
}
For further details, have a look at this answer.
JSON Web Token
JSON Web Token (JWT) is defined by the RFC 7519 and I think it fits really well for your needs.
It's a standard method for representing claims securely between two parties (in this situation, client and server). JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64.
The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server.
To find some great resources to work with JWT, have a look at http://jwt.io.
And remember: when sending sensitive data over the wire, your best friend is HTTPS. It protects your application against the man-in-the-middle attack.
Tracking the tokens
You won't need to persist JWT tokens if you don't need to track them.
Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To keep the track of JWT tokens, instead of persisting the whole token, you could persist the token identifier (the jti claim) and some metadata (the user you issued the token for, the expiration date, etc) if you need.
There are many databases where you can persist your tokens. Depending on your requirements, you can explore different solutions such as relational databases, key-value stores or document stores.
Your application can provide some functionality to revoke the tokens, but always consider revoking the tokens when the users change their password. When persisting tokens, always consider removing the old ones in order to prevent your database from growing indefinitely.
