> On 22 Jul 2016, at 19:20, Johan Brichau <jo...@inceptive.be> wrote: > > Hey Norbert, > > Also see here: http://smalltalkhub.com/#!/~JohanBrichau/Json-WebToken > > ;)
And now we have not one but two implementations ? I would guess Johan's version is more Seaside oriented, or not ? > 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 >>
