Hey Norbert, Also see here: http://smalltalkhub.com/#!/~JohanBrichau/Json-WebToken
;) Are you using cryptography package? Cheers, Johan > On 22 Jul 2016, at 10:17, Norbert Hartl <norb...@hartl.name> wrote: > > 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 >
