Thank you for sharing Norbert. Best regards, Hernán
2016-07-22 5:17 GMT-03:00 Norbert Hartl <[email protected]>: > Hi, > > thanks to the inquiry of Sven I published an implementation of > JSONWebToken to smalltalkhub. It is available at > > http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken > > For those who don't know JSONWebToken or short JWT pronounced "jot" is a > token format suitable for authentication and authorization. The token > consist of a header, a payload and a signature. The header defines crypto > algorithms, compression and other things needed to read a token on > reception. The payload is called a claim set which is basically a > dictionary with well-known and custom keys. If we think about OAuth or > OpenId the values contained map directly to JWT claims. For OpenID connect > which is an identification mechanism on top of OAuth the usage of JWT is > one of the building blocks. > > What are the advantages in using JWT? > > - it defines a header for encoding the content so it is quite flexible in > the ways compression and encryption of the key is done > - defines a payload which maps arbitrary keys and there is a set of > well-known keys that implementations of OAuth, OpenID can understand > - defines a signature that makes it easy to trust the information > contained or to give the token to someone who is not trusted > - token format is a single line string so it can be used e.g. in HTTP > authentication headers > > A problem JWT can solve: > > In our company we have a lot of little REST servers serving some duties. > To minimize the chaos I want to have a central authentication and > authorization point. If we assume having 20 images running and we look at > typical way how authorization works: > > there is image A (Authentication), image S (Service) und client C. Client > C wants to use the service S > > 1. client C authenticates and retrieves authorization information from A > (or from S which redirects him to A) > 2. client C hands out the authorization information to S > 3. S needs to check at A if the information is valid (client C could have > modified it or generated it) > 4. S grants C access > > Taking the assumption of having 20 service images, every image would need > to get back to A in order to check authorization information. The more > services images you have the more load it will put on A. In a JWT use case > scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization > information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization > information contained is valid. > 4. S grants C access > > FYI, > > Norbert > >
