{"id":58652,"date":"2016-07-25T12:10:57","date_gmt":"2016-07-25T09:10:57","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=58652"},"modified":"2016-08-01T23:48:02","modified_gmt":"2016-08-01T20:48:02","slug":"token-authentication-java-applications","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2016\/07\/token-authentication-java-applications.html","title":{"rendered":"Token Authentication for Java Applications"},"content":{"rendered":"

Building Identity Management, including authentication and authorization? Try Stormpath! Our REST API and robust Java SDK support<\/a> can eliminate your security risk and can be implemented in minutes. Sign up<\/a>, and never build auth again!<\/span><\/p>\n

Update 5\/12\/2016:<\/strong> Building a Java application? JJWT<\/a> is a Java library providing end-to-end JWT creation and verification, developed by our very own Les Hazlewood. Forever free and open-source (Apache License, Version 2.0), JJWT is simple to use and understand. It was designed with a builder-focused fluent interface hiding most of its complexity. We\u2019d love to have you try it out<\/a>, and let us know what you think! (And, if you\u2019re a Node developer, check out NJWT<\/a>!)<\/p>\n

In my last post<\/a>, we covered a lot of ground, including how we traditionally go about securing websites, some of the pitfalls of using cookies and sessions, and how to address those pitfalls by traditional means.<\/p>\n

In this post we\u2019ll go beyond the traditional and take a deep dive into how token authentication with JWTs (JSON Web Tokens) not only addresses these concerns, but also gives us the benefit of inspectable meta-data and strong cryptographic signatures.<\/p>\n

Token Authentication to the Rescue!<\/h2>\n

Let\u2019s first examine what we mean by authentication<\/code> and token<\/code> in this context.<\/p>\n

Authentication is proving that a user is who they say they are.<\/p>\n

A token is a self-contained singular chunk of information. It could have intrinsic value or not. We are going to look at a particular type of token that does<\/em> have intrinsic value and addresses a number of the concerns with session IDs.<\/p>\n

JSON Web Tokens (JWTs)<\/h3>\n

JWTs are a URL-safe, compact, self-contained string with meaningful information that is usually digitally signed or encrypted. They\u2019re quickly becoming a de-facto standard for token implementations across the web.<\/p>\n

URL-safe is a fancy way of saying that the entire string is encoded so there are no special characters and the token can fit in a URL.<\/p>\n

The string is opaque and can be used standalone in much the same way that session IDs are used. By opaque, I mean that looking at the string itself provides no additional information.<\/p>\n

However, the string can also be decoded to pull out-meta data and it\u2019s signature can be cryptographically verified so that your application knows that the token has not been tampered with.<\/p>\n

JWTs and OAuth2 Access Tokens<\/h4>\n

Many OAuth2 implementations are using JWTs for their access tokens. It should be stated that the OAuth2 and JWT specifications are completely separate from each other and don\u2019t have any dependencies on each other. Using JWTs as the token mechanism for OAuth2 affords a lot of benefit as we\u2019ll see below.<\/p>\n

JWTs can be stored in cookies, but all the rules for cookies we discussed before<\/a> still apply. You can entirely replace your session id with a JWT. You can then gain the additional benefit of accessing the meta-information directly from that session id.<\/p>\n

In the wild, they look like just another ugly string:<\/p>\n

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vdHJ1c3R5YXBwLmNvbS8iLCJleHAiOjEzMDA4MTkzODAsInN1YiI6InVzZXJzLzg5ODM0NjIiLCJzY29wZSI6InNlbGYgYXBpL2J1eSJ9.43DXvhrwMGeLLlP4P4izjgsBB2yrpo82oiUPhADakLs<\/pre>\n
If you look carefully, you can see that there are two periods in the string. These are significant as they delimit different sections of the JWT.<\/p>\n
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9\r\n.\r\neyJpc3MiOiJodHRwOi8vdHJ1c3R5YXBwLmNvbS8iLCJleHAiOjEzMDA4MTkzODAsInN1YiI6InVzZXJzLzg5ODM0NjIiLCJzY29wZSI6InNlbGYgYXBpL2J1eSJ9\r\n.\r\n43DXvhrwMGeLLlP4P4izjgsBB2yrpo82oiUPhADakLs<\/pre>\n
JWT Structure<\/h4>\n
JWTs have a three part structure, each of which is base64-encoded:<\/p>\n
\"jwt_parts\"<\/a><\/p>\n
Here are the parts decoded:<\/p>\n
Header<\/strong><\/p>\n
{\r\n  \"typ\": \"JWT\",\r\n  \"alg\": \"HS256\"\r\n}<\/pre>\n
Claims<\/strong><\/p>\n
{\r\n  \"iss\":\"http:\/\/trustyapp.com\/\",\r\n  \"exp\": 1300819380,\r\n  \"sub\": \"users\/8983462\",\r\n  \"scope\": \"self api\/buy\"\r\n}<\/pre>\n
Cryptographic Signature<\/strong><\/p>\n
t\u00df\u00b4\u2014\u2122\u00e0%O\u02dcv+n\u00ee\u2026SZu\u00af\u00b5\u20acU\u20268H\u00d7<\/pre>\n
JWT Claims<\/h4>\n
Let\u2019s examine the claims sections. Each type of claim that is part of the JWT Specification can be found here<\/a>.<\/p>\n
iss<\/code> is who issued the token.
\nexp<\/code> is when the token expires.
\nsub<\/code> is the subject of the token. This is usually a user identifier of some sort.<\/p>\n
The above parts of the claim are all included in the JWT specification. scope<\/code> is not included in the specification, but it is commonly used to provide authorization information. That is, what parts of the application the user has access to.<\/p>\n
One advantage of JWTs is that arbitrary data can be encoded into the claims as with scope<\/code> above. Another advantage is that the client can now react to this information without any further interaction with the server. For instance, a portion of the page may be hidden based on the data found in thescope<\/code> claim.<\/p>\n
NOTE<\/strong>: It is still critical and a best practice for the server to always verify actions taken by the client. If, for instance, some administrative action was being taken on the client, you would still want to verify on the application server that the current user had permission to perform that action. You would never rely on client side authorization information alone.<\/p>\n
You may have picked up on another advantage: the cryptographic signature. The signature can be verified which proves that the JWT has not been tampered with. Note that the presence of a crytpographic signature does not guarantee confidentiality. Confidentiality is ensured only when the JWT is encrypted as well as<\/em> signed.<\/p>\n
Now, for the big kicker: statelessness<\/strong>. While the server will need to generate the JWT, it does not need to store it anywhere as all of the user meta-data is encoded right in to the JWT. The server and client could pass the JWT back and forth and never store it. This scales very well.<\/p>\n
Managing Bearer Token Security<\/h3>\n
Implicit trust is a tradeoff. These types of tokens are often referred to as Bearer Tokens because all that is required to gain access to the protected sections of an application is the presentation of a valid, unexpired token.
 
<\/div> <\/div><\/p>\n
You have to address issues like: How long should the token be good for? How will you revoke it? (There\u2019s a whole other post we could do on refresh tokens<\/a>.)<\/p>\n
You have to be mindful of what you store in the JWT if they are not encrypted. Do not<\/em> store any sensitive information. It is generally accepted practice to store a user identifier in the form of the sub<\/code>claim. When a JWT is signed, it\u2019s referred to as a JWS. When it\u2019s encrypted, it\u2019s referred to as a JWE.<\/p>\n
Java, JWT and You!<\/h3>\n
We are very proud of the JJWT<\/a> project on Github. Primarily authored by Stormpath\u2019s own CTO, Les Hazlewood<\/a>, it\u2019s a fully open-source JWT solution for Java. It\u2019s the easiest to use and understand library for creating and verifying JSON Web Tokens on the JVM.<\/p>\n
How do you create a JWT? Easy peasy!<\/p>\n
import io.jsonwebtoken.Jwts;\r\nimport io.jsonwebtoken.SignatureAlgorithm;\r\n \r\nbyte[] key = getSignatureKey();\r\n \r\nString jwt = \r\n    Jwts.builder().setIssuer(\"http:\/\/trustyapp.com\/\")\r\n        .setSubject(\"users\/1300819380\")\r\n        .setExpiration(expirationDate)\r\n        .put(\"scope\", \"self api\/buy\") \r\n        .signWith(SignatureAlgorithm.HS256,key)\r\n        .compact();<\/pre>\n
The first thing to notice is the fluent<\/a> builder api used to create a JWT. Method calls are chained culminating in the compact<\/code> call which returns the final JWT string.<\/p>\n
Also notice that when we are setting one of the claims from the specification, we use a setter. For example: .setSubject(\"users\/1300819380\")<\/code>. When a custom claim is set, we use a call to put and specify both the key and value. For example: .put(\"scope\", \"self api\/buy\")<\/code><\/p>\n
It\u2019s just as easy to verify a JWT.<\/p>\n
String subject = \"HACKER\";\r\ntry {\r\n    Jws jwtClaims = \r\n        Jwts.parser().setSigningKey(key).parseClaimsJws(jwt);\r\n \r\n    subject = claims.getBody().getSubject();\r\n \r\n    \/\/OK, we can trust this JWT\r\n \r\n} catch (SignatureException e) {\r\n \r\n    \/\/don't trust the JWT!\r\n}<\/pre>\n
If the JWT has been tampered with in any way, parsing the claims will throw a SignatureException<\/code>and the value of the subject<\/code> variable will stay HACKER<\/code>. If it\u2019s a valid JWT, then subject<\/code> will be extracted from it: claims.getBody().getSubject()<\/code><\/p>\n
What is OAuth?<\/h3>\n
In the next section, we\u2019ll look at an example using Stormpath\u2019s OAuth2 implementation, which makes use of JWTs.<\/p>\n
There\u2019s a lot of confusion around the OAuth2 spec. That\u2019s, in part, because it is really an \u00fcber spec \u2013 it has a lot of complexity. It\u2019s also because OAuth1.a and OAuth2 are very different beasts. We are going to look at a very specific, easy to use, subset of the OAuth2 spec. We have an excellent post that goes into much more detail on What the Heck is OAuth<\/a>. Here, we\u2019ll give some brief background and then jump right into the examples.<\/p>\n
OAuth2 is basically a protocol that supports authorization workflows<\/strong>. What this means is that it gives you a way to ensure that a specific user has permissions to do something.<\/p>\n
That\u2019s it.<\/p>\n
OAuth2 isn\u2019t<\/em> meant to do stuff like validate a user\u2019s identity \u2014 that\u2019s taken care of by an Authentication service. Authentication is when you validate a user\u2019s identity (like asking for a username \/ password to log in<\/em>), whereas authorization is when you check to see what permissions an existing user already has.<\/p>\n
Just remember that OAuth2 is a protocol for authorization<\/em>.<\/p>\n
Using OAuth Grant Types for Authorization<\/h4>\n
Let\u2019s look at a typical OAuth2 interaction.<\/p>\n
POST \/oauth\/token HTTP\/1.1\r\nOrigin: https:\/\/foo.com\r\nContent-Type: application\/x-www-form-urlencoded\r\n \r\ngrant_type=password&amp;username=username&amp;password=password<\/pre>\n
grant_type<\/code> is required. The application\/x-www-form-urlencoded<\/code> content type is required for this type of interaction as well. Given that you are passing the username and password over the wire, you would always<\/em> want the connection to be secure. The good thing, however, is that the response will have an OAuth2 bearer token. This token will then be used for every interaction between the browser and server going forward. There is a very brief exposure here where the username and password are passed over the wire. Assuming the authentication service on the server verifies the username and password, here\u2019s the response:<\/p>\n
HTTP\/1.1 200 OK\r\nContent-Type: application\/json;charset=UTF-8\r\nCache-Control: no-store\r\nPragma: no-cache\r\n \r\n{\r\n    \"access_token\":\"2YotnFZFEjr1zCsicMWpAA...\",\r\n    \"token_type\":\"example\",\r\n    \"expires_in\":3600,\r\n    \"refresh_token\":\"tGzv3JOkF0XG5Qx2TlKWIA...\",\r\n    \"example_parameter\":\"example_value\"\r\n}<\/pre>\n
Notice the Cache-Control<\/code> and Pragma<\/code> headers. We don\u2019t want this response being cached anywhere. The access_token<\/code> is what will be used by the browser in subsequent requests. Again, there is not direct relationship between OAuth2 and JWT. However, the access_token<\/code> can be a JWT. That\u2019s where the extra benefit of the encoded meta-data comes in. Here\u2019s how the access token is leveraged in future requests:<\/p>\n
GET \/admin HTTP\/1.1\r\nAuthorization: Bearer 2YotnFZFEjr1zCsicMW...<\/pre>\n
The Authorization<\/code> header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic<\/code>, in this case the type is Bearer<\/code>. The access token is included directly after the Bearer<\/code> keyword. This completes the OAuth2 interaction for the password grant type. Every subsequent request from the browser can use the Authorizaion: Bearer<\/code> header with the access token.<\/p>\n
There\u2019s another grant type known as client_credentials<\/code> which uses client_id<\/code> andclient_secret<\/code>, rather than username<\/code> and password<\/code>. This grant type is typically used for API interactions. While the client id and slient secret function similarly to a username and password, they are usually of a higher quality security and not necessarily human readable.<\/p>\n
Take Us Home: OAuth2 Java Example<\/h2>\n
We\u2019ve arrived! It\u2019s time to dig into some specific code that demonstrates JWTs in action.<\/p>\n
Spring Boot Web MVC<\/h3>\n
There are a number of examples in the Stormpath Java SDK<\/a>. Here, we are going to look at a Spring Boot Web MVC example. Here\u2019s the HelloController<\/a> from the example:<\/p>\n
@RestController\r\npublic class HelloController {\r\n \r\n    @RequestMapping(\"\/\")\r\n    String home(HttpServletRequest request) {\r\n \r\n        String name = \"World\";\r\n \r\n        Account account = AccountResolver.INSTANCE.getAccount(request);\r\n        if (account != null) {\r\n            name = account.getGivenName();\r\n        }\r\n \r\n        return \"Hello \" + name + \"!\";\r\n    }\r\n \r\n}<\/pre>\n
The key line, for the purposes of this demonstration is:<\/p>\n
Account account = AccountResolver.INSTANCE.getAccount(request);<\/code><\/p>\n
Behind the scenes, account<\/code> will resolve to an Account<\/code> object (and not be null<\/code>) ONLY if an authenticated session is present.<\/p>\n
Build and Run the Example Code<\/h3>\n
To build and run this example, do the following:<\/p>\n
\u263a dogeared jobs:0 ~\/Projects\/StormPath\/stormpath-sdk-java (master|8100m)\r\n\u27a5 cd examples\/spring-boot-webmvc\/\r\n\u263a dogeared jobs:0 ~\/Projects\/StormPath\/stormpath-sdk-java\/examples\/spring-boot-webmvc (master|8100m)\r\n\u27a5 mvn clean package\r\n[INFO] Scanning for projects...\r\n[INFO]\r\n[INFO] ------------------------------------------------------------------------\r\n[INFO] Building Stormpath Java SDK :: Examples :: Spring Boot Webapp 1.0.RC4.6-SNAPSHOT\r\n[INFO] ------------------------------------------------------------------------\r\n \r\n... skipped output ...\r\n \r\n[INFO] ------------------------------------------------------------------------\r\n[INFO] BUILD SUCCESS\r\n[INFO] ------------------------------------------------------------------------\r\n[INFO] Total time: 4.865 s\r\n[INFO] Finished at: 2015-08-04T11:46:05-04:00\r\n[INFO] Final Memory: 31M\/224M\r\n[INFO] ------------------------------------------------------------------------\r\n\u263a dogeared jobs:0 ~\/Projects\/StormPath\/stormpath-sdk-java\/examples\/spring-boot-webmvc (master|8100m<\/pre>\n
Launch the Spring Boot Example<\/h3>\n
You can then launch the Spring Boot example like so:<\/p>\n
\u263a dogeared jobs:0 ~\/Projects\/StormPath\/stormpath-sdk-java\/examples\/spring-boot-webmvc (master|8104m)\r\n\u27a5 java -jar target\/stormpath-sdk-examples-spring-boot-web-1.0.RC4.6-SNAPSHOT.jar\r\n \r\n  .   ____          _            __ _ _\r\n \/\\\\ \/ ___'_ __ _ _(_)_ __  __ _ \\ \\ \\ \\\r\n( ( )\\___ | '_ | '_| | '_ \\\/ _` | \\ \\ \\ \\\r\n \\\\\/  ___)| |_)| | | | | || (_| |  ) ) ) )\r\n  '  |____| .__|_| |_|_| |_\\__, | \/ \/ \/ \/\r\n =========|_|==============|___\/=\/_\/_\/_\/\r\n :: Spring Boot ::        (v1.2.1.RELEASE)\r\n \r\n2015-08-04 11:51:00.127  INFO 17973 --- [           main] tutorial.Application                     : Starting Application v1.0.RC4.6-SNAPSHOT on MacBook-Pro.local with PID 17973 \r\n \r\n... skipped output ...\r\n \r\n2015-08-04 11:51:04.558  INFO 17973 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)\r\n2015-08-04 11:51:04.559  INFO 17973 --- [           main] tutorial.Application                     : Started Application in 4.599 seconds (JVM running for 5.103)<\/pre>\n
NOTE<\/strong>: This assumes that you\u2019ve already setup a Stormpath account and that your api keys are located in ~\/.stormpath\/apiKey.properties<\/code>. Look here<\/a> for more information on quick setup up of Stormpath with Spring Boot.<\/p>\n
Authenticate with a JSON Web Token (or Not)<\/h3>\n
Now, we can exercise the example and show some JWTs in action! First, hit your endpoint without any authentication. I like to use httpie<\/a>, but any command line http client will do.<\/p>\n
\u27a5 http -v localhost:8080\r\nGET \/ HTTP\/1.1\r\nAccept: *\/*\r\nAccept-Encoding: gzip, deflate\r\nConnection: keep-alive\r\nHost: localhost:8080\r\nUser-Agent: HTTPie\/0.9.2\r\n \r\n \r\nHTTP\/1.1 200 OK\r\nAccept-Charset: big5, big5-hkscs, cesu-8, euc-jp, euc-kr, gb18030, ... \r\nContent-Length: 12\r\nContent-Type: text\/plain;charset=UTF-8\r\nDate: Tue, 04 Aug 2015 15:56:41 GMT\r\nServer: Apache-Coyote\/1.1\r\n \r\nHello World!<\/pre>\n
The -v<\/code> parameter produces verbose output and shows all the headers for the request and the response. In this case, the output message is simply: Hello World!<\/code>. This is because there is not an established session.<\/p>\n
Authenticate with the Stormpath OAuth Endpoint<\/h4>\n
Now, let\u2019s hit the oauth<\/code> endpoint so that our server can authenticate with Stormpath. You may ask, \u201cWhat oauth<\/code> endpoint?\u201d The controller above doesn\u2019t indicate any such endpoint. Are there other controllers with other endpoints in the example? No, there are not! Stormpath gives you oauth (and many other) endpoints right out-of-the-box. Check it out:<\/p>\n
\u27a5 http -v --form POST http:\/\/localhost:8080\/oauth\/token  \\\r\n&gt; 'Origin:http:\/\/localhost:8080' \\\r\n&gt; grant_type=password username=micah+demo.jsmith@stormpath.com password=\r\nPOST \/oauth\/token HTTP\/1.1\r\nContent-Type: application\/x-www-form-urlencoded; charset=utf-8\r\nHost: localhost:8080\r\nOrigin: http:\/\/localhost:8080\r\nUser-Agent: HTTPie\/0.9.2\r\n \r\ngrant_type=password&amp;username=micah%2Bdemo.jsmith%40stormpath.com&amp;password=\r\n \r\nHTTP\/1.1 200 OK\r\nCache-Control: no-store\r\nContent-Length: 325\r\nContent-Type: application\/json;charset=UTF-8\r\nDate: Tue, 04 Aug 2015 16:02:08 GMT\r\nPragma: no-cache\r\nServer: Apache-Coyote\/1.1\r\nSet-Cookie: account=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxNDQyNmQxMy1mNThiLTRhNDEtYmVkZS0wYjM0M2ZjZDFhYzAiLCJpYXQiOjE0Mzg3MDQxMjgsInN1YiI6Imh0dHBzOi8vYXBpLnN0b3JtcGF0aC5jb20vdjEvYWNjb3VudHMvNW9NNFdJM1A0eEl3cDRXaURiUmo4MCIsImV4cCI6MTQzODk2MzMyOH0.wcXrS5yGtUoewAKqoqL5JhIQ109s1FMNopL_50HR_t4; Expires=Wed, 05-Aug-2015 16:02:08 GMT; Path=\/; HttpOnly\r\n \r\n{\r\n    \"access_token\": \"eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxNDQyNmQxMy1mNThiLTRhNDEtYmVkZS0wYjM0M2ZjZDFhYzAiLCJpYXQiOjE0Mzg3MDQxMjgsInN1YiI6Imh0dHBzOi8vYXBpLnN0b3JtcGF0aC5jb20vdjEvYWNjb3VudHMvNW9NNFdJM1A0eEl3cDRXaURiUmo4MCIsImV4cCI6MTQzODk2MzMyOH0.wcXrS5yGtUoewAKqoqL5JhIQ109s1FMNopL_50HR_t4\",\r\n    \"expires_in\": 259200,\r\n    \"token_type\": \"Bearer\"\r\n}<\/pre>\n
There\u2019s a lot going on here, so let\u2019s break it down.<\/p>\n
On the first line, I am telling httpie<\/code> that I want to make a form url-encoded POST \u2013 that\u2019s what the --form<\/code> and POST<\/code> parameters do. I am hitting the \/oauth\/token<\/code> endpoint of my locally running server. I specify an Origin<\/code> header. This is required to interact with Stormpath for the security reasons we talked about previously<\/a>. As per the OAuth2 spec, I am passing up grant_type=password<\/code> along with ausername<\/code> and password<\/code>.<\/p>\n
The response has a Set-Cookie<\/code> header as well as a JSON body containing the OAuth2 access token. And guess what? That access token is also a JWT. Here are the claims decoded:<\/p>\n
{\r\n  \"jti\": \"14426d13-f58b-4a41-bede-0b343fcd1ac0\",\r\n  \"iat\": 1438704128,\r\n  \"sub\": \"https:\/\/api.stormpath.com\/v1\/accounts\/5oM4WI3P4xIwp4WiDbRj80\",\r\n  \"exp\": 1438963328\r\n}<\/pre>\n
Notice the sub<\/code> key. That\u2019s the full Stormpath URL to the account I authenticated as. Now, let\u2019s hit our basic Hello World endpoint again, only this time, we will use the OAuth2 access token:<\/p>\n
\u27a5 http -v localhost:8080 \\\r\n&gt; 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxNDQyNmQxMy1mNThiLTRhNDEtYmVkZS0wYjM0M2ZjZDFhYzAiLCJpYXQiOjE0Mzg3MDQxMjgsInN1YiI6Imh0dHBzOi8vYXBpLnN0b3JtcGF0aC5jb20vdjEvYWNjb3VudHMvNW9NNFdJM1A0eEl3cDRXaURiUmo4MCIsImV4cCI6MTQzODk2MzMyOH0.wcXrS5yGtUoewAKqoqL5JhIQ109s1FMNopL_50HR_t4'\r\nGET \/ HTTP\/1.1\r\nAuthorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxNDQyNmQxMy1mNThiLTRhNDEtYmVkZS0wYjM0M2ZjZDFhYzAiLCJpYXQiOjE0Mzg3MDQxMjgsInN1YiI6Imh0dHBzOi8vYXBpLnN0b3JtcGF0aC5jb20vdjEvYWNjb3VudHMvNW9NNFdJM1A0eEl3cDRXaURiUmo4MCIsImV4cCI6MTQzODk2MzMyOH0.wcXrS5yGtUoewAKqoqL5JhIQ109s1FMNopL_50HR_t4\r\nConnection: keep-alive\r\nHost: localhost:8080\r\nUser-Agent: HTTPie\/0.9.2\r\n \r\n \r\n \r\nHTTP\/1.1 200 OK\r\nContent-Length: 11\r\nContent-Type: text\/plain;charset=UTF-8\r\nDate: Tue, 04 Aug 2015 16:44:28 GMT\r\nServer: Apache-Coyote\/1.1\r\n \r\nHello John!<\/pre>\n
Notice on the last line of the output that the message addresses us by name. Now that we\u2019ve established an authenticated session with Stormpath using OAuth2, these lines in the controller retrieve the first name:<\/p>\n
Account account = AccountResolver.INSTANCE.getAccount(request);\r\nif (account != null) {\r\n    name = account.getGivenName();\r\n}<\/pre>\n
Summary: Token Authentication for Java Apps<\/h2>\n
In this post, we\u2019ve looked at how token authentication with JWTs not only addresses the concerns of traditional approaches, but also gives us the benefit of inspectable meta-data and strong cryptographic signatures.<\/p>\n
We gave an overview of the OAuth2 protocol and went through a detailed example of how Stormpath\u2019s implementation of OAuth2 uses JWTs.<\/p>\n
Here are some other links to posts on token based authentication, JWTs and Spring Boot:<\/p>\n