2

I've worked on a Spring 4 MVC RESTful backend application. We authenticate to an OpenAM server, and a lengthy token is stored in a cookie on the front-end. The front-end takes the token out of the cookie, and passes it back as a header in every Ajax call to the back-end. So, if we call the RESTful backend in an Ajax call (POST, PUT, GET), the token is sent as a header called "openam_token."

We have implemented Spring Web-Security based on the SiteHeader example. A token comes in as a header and we have a PreAuthorizationFilter which we implemented called "CustomUserDetailsService." This code takes the header, and gets the token, we pass that token to OpenAM to ask them if this is valid, and if so, returns us the username of that user. From that unique username, we can lookup the user in the database and get the user details and their roles.

I presume that if I created a Login from Google+, LinkedIn, or Facebook, the process is the same. We flip to their login page, the user gets authenticated and then a token comes back. The token gets stored in a cookie on the client side. Every Ajax call from that front-end to the backend passes back the token in the header,and then in CustomUserDetailsService ...we call LinkedIn, Google+, or Facebook, and see if the user is correct. But this is on my presumption of how these work, but I could be completely wrong.

So, on the Spring RESTful app I am working on. Usernames and passwords are stored in the database along with the salt. I've done a lot of research on storing the salt with the username, a unique salt generated when the user is created or when they change their password.

So, provided a user provides a username and password, and the user has authenticated ... I want to generate a token for this user, and I am wondering on what the common practices are for generating a token?

Second,where is the best place to store that token? If the token comes back, then I presume I can save that in a cookie on the client side as well, just like we do when we authenticate against OpenAM. Now, what would be the best way to store those temporary tokens on the backend? I could persist the token in the users table along with the user. I could store those tokens in another table. The idea is ... the tokens, stored in the cookies, need to match on the backend for that user with that token. So, the question is on what a godd strategy for doing that.

I understand that I will never have the 100% most secured site, but I can take some common steps and do my due diligence.

Seems like an awful lot of explanation for something that seems like an easy question.

Thanks!

Improve this question

1 Answer 1

Reset to default
1

Token length of 256 bits, it's 42 characters in base64. It needs to be random.

Token is usually stored in cache with user session. For example, Redis. Every other storage method would do and it will vary with responsiveness, e.g. fetching long JSON from tmpfs and from SQL DB is different. Compression helps.

This can be other local service. For example, token service which holds API keys.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .