Characteristics of Shiro User Authentication with REST

This is a very informative forum thread on approaches to Shiro User Authentication for REST applications. Several takeaways, one being to set any REST paths with the noSessionCreation filter. 

Les Hazlewood writes:

For web-scale scalability, most REST implementors prefer that REST APIs should be stateless.  While you can have REST APIs that use sessions, most choose to remain stateless and authenticate on every request as a best practice. Assuming you'll authenticate every request, your token will be the data you'll need to submit to Shiro on each request.

In security circles, this is known as a 'bearer token' - the data isn't actual authentication principals+credentials, instead it is a token that you automatically assume that the presenter of the token (aka 'holder' or 'bearer') is allowed to have it and you can trust it.  I should point out that bearer tokens are less secure than other mechanisms, but I won't talk about that here, as that is a different thread entirely.  But sometimes (e.g. your case?) maybe they're the only mechanism that can be used.

Posted August 08, 2017 12:30 PM EDT

More Like This Post