From 288812cda70a26605454b8f21b401ce01a925c0e Mon Sep 17 00:00:00 2001 From: svlada Date: Sun, 28 Aug 2016 15:00:14 +0200 Subject: [PATCH] Work on blog. --- etc/blog.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/etc/blog.md b/etc/blog.md index 58e2a85..b4797f1 100644 --- a/etc/blog.md +++ b/etc/blog.md @@ -490,10 +490,28 @@ JWT Authentication flow is very simple: 1. User obtains Refresh and Access tokens by providing credentials to Authorization server 2. User sends Access token with each request to access protected API resource -3. Access token is signed and contains user identity(e.g. user id) and authorization claims. It's important to note that authorization claims will be included with the Access token. Why is this important? Well, let's say that authorization claims(e.g user privileges in the database) are changed during the life time of Access token. Those changes will not become effective until new Access token is issued. In most cases this is not big issue, because Access tokens are short-lived. Otherwise go with the opaque token pattern. +3. Access token is signed and contains user identity(e.g. user id) and authorization claims. + +It's important to note that authorization claims will be included with the Access token. Why is this important? Well, let's say that authorization claims(e.g user privileges in the database) are changed during the life time of Access token. Those changes will not become effective until new Access token is issued. In most cases this is not big issue, because Access tokens are short-lived. Otherwise go with the opaque token pattern. + +Before we get to the details of the implementation, let's look at the request/response authentication flow. + +**Signed request to protected API resource** + + + + + + + + + + #### WebSecurityConfig + + WebSecurityConfig class is where all security related configuration reside.