Hi, thanks to the inquiry of Sven I published an implementation of JSONWebToken to smalltalkhub. It is available at http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken <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
On 22 Jul 2016, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
Hi!
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
thank you for the information! I have one rather specific question. How is the token normally transported from C to S? Part of the body/data of a POST/PUT/GET? A custom header inside the HTTP request? kind regards holger
Am 22.07.2016 um 11:47 schrieb Holger Freyther <holger@freyther.de>:
On 22 Jul 2016, at 16:17, Norbert Hartl <norbert@hartl.name> wrote:
Hi!
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
thank you for the information! I have one rather specific question. How is the token normally transported from C to S? Part of the body/data of a POST/PUT/GET? A custom header inside the HTTP request?
It is up to you how you like to do it. It could be: - Client C asks A for authorization and gets back a JWT in the response body - Client C adds the JWT token as HTTP Header "Authorization: Bearer [token]" to ask the service in a usual fashion - Service S checks signature of token and extracts permission set and grants them or - Client C asks service S to do something - Service S redirects C to A giving a redirect_url as query parameter in the url - A checks authorization with C and then redirects the request to the request_uri having the token as query parameter of the uri or - Client C asks service S to do something - Service S redirects C to A giving a redirect_url as query parameter in the url - A checks authorization with C and then redirects the request to the request_uri having an exchange code in the query parameters - S exchange at A the exchange code with authorization token There are plenty of scenarios possible. It depends if it is about authorization or authentication and which "standard" to use. You can always roll your own. If you have many services it could be feasible to combine all permissions you need into one JWT then send it to A. If your claims are valid you get back the signed token from A. You could then use the same token for all your servicesâ¦. Hope this helps, Norbert
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 <norbert@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
On 22 Jul 2016, at 19:20, Johan Brichau <johan@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 <norbert@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
Hey Johan, didn't find it when starting my own. Mine is between 2 and 3 years old. Maybe parallel development ;) Mine is pretty basic and uses only SHA256. I implemented for internal use and just released as sven was asking. Norbert
Am 22.07.2016 um 19:20 schrieb Johan Brichau <johan@inceptive.be>:
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 <norbert@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
Hi, You can blame me for that because I could not find a JSON web token. It would be nice to have a search facility. Or am I missing an obvious feature I should be using? I am mostly experienced with cincom smalltalk. I like Pharo. My only criticism is that thing could be easier to set up. I am still trying to figure out how to get a commit to a git repository hosted of bit buck to commit etc. The customer set it there not me. I just have to get it to work ;-) Sean Kind Regards, Sean Glazier On Fri, Jul 22, 2016 at 5:45 PM, Norbert Hartl <norbert@hartl.name> wrote:
Hey Johan,
didn't find it when starting my own. Mine is between 2 and 3 years old. Maybe parallel development ;) Mine is pretty basic and uses only SHA256. I implemented for internal use and just released as sven was asking.
Norbert
Am 22.07.2016 um 19:20 schrieb Johan Brichau <johan@inceptive.be>:
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 <norbert@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
Sean Glazier wrote
I am still trying to figure out how to get a commit to a git repository hosted of bit buck to commit etc.
The simplest thing you can do is create a filetree:// repo via the Monticello Browser pointing to your local git clone and deal with it as any other repo. ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-JSONWebToken-tp4907439p4907661.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (6)
-
Holger Freyther -
Johan Brichau -
Norbert Hartl -
Sean Glazier -
Sean P. DeNigris -
Sven Van Caekenberghe