What is JSON?
JSON (JavaSript Object Notation) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays. It is a common data format with diverse uses in electronic data interchange, including that of web applications with servers. JSON is "self-describing," which makes it easier for humans to read and understand. In the past, data was interchanged with XML. Recently, JSON has been gaining traction as a standard for data interchange from one server or web application to another.
The following snippet is an example of a standard JSON object.
{
"firstName":"John",
"lastName":"Doe",
"email":"jdoe@mycompany.com"
}
You can see that there is clearly specified attribute and value pairs that are straightforward to understand. For example, the above user's first name can be seen from the "firstName" attribute and its value is "John."
What is JWT?
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA, two of the worlds most widely adopted encryption algorithms.
Benefits of Using JWT SSO v SAML SSO
As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.
JWT and SAML tokens can use a public/private key pair in the form of a X.509 certificate for signing. Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.
JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn't have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.
Regarding usage, JWT is used at Internet scale. This highlights the ease of client-side processing of the JSON Web token on multiple platforms, especially mobile.
To get an idea of the differences between JWT and SAML, observe the following example of an attribute statement containing a user's first name, last name and email address in the context of an SSO assertion payload:
JWT
{
"FirstName":"John",
"LastName":"Doe",
"Email":"jdoe@mycompany.com"
}
SAML
<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Attribute Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">John</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Doe</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">jdoe@mycompany.com</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
How Does JWT SSO Work?
There are two elements to a JWT SSO, the Authentication Server and the Client.
Authentication Server: In JWT SSO, this will be the Identity Provider (IdP). The Authentication Server is the source for the username and other user attributes that will be bundled into the assertion and sent to the client.
Client: In JWT SSO, this is the Service Provider (SP).
When the user successfully logs in using their credentials to the IdP, a JSON Web Token will be returned and stored in browser storage. When a user wants to SSO into external client, the stored JWT is passed in the browser URL which is verified by the client.
Requirements for Implementing JWT
Allbound as Authentication Server
When Allbound is the Authentication Server, we require a few fields from the Client.
Algorithm: This field is provided by the client. This is the client's preferred JWT signing algorithm. As the identity provider Allbound supports three different algorithms: HS256, HS384, HS512. If none is preferred you may set it on any.
Response Key: This field is provided by the client. By default this will be jwt
. This key is used to send the token to the redirect URL usually it will be jwt or id_token.
Redirect URL: This field is provided by the client. The redirect URL is used to redirect the user to the client along with the JWT token appended to the URL.
Configure Available Attributes
By default Allbound sends the following attributes when available in the JWT payload:
FirstName
LastName
You can override these attribute names by adding the attribute name in this section. Attribute key is the name of the attribute that the client expects. Attribute value is taken from the user meta. You can also add additional attributes and map them to what the client expects.
Allbound as Client
As the client Allbound will require most of the information from the authorization server. The IDP will only require redirect URL. The redirect URL is: `https://[instance_url]/jwt/{sp_id}`.
Secret Key: This secret should be provided by the authorization server or it can be any string that both parties agree to.
Redirect Key: This is the key used to send our redirect URL to an SSO request if Allbound initiates the request.
Attributes: These fields are provided by the authorization server. These fields are optional. If none are provided Allbound will only be looking for Email, FirstName and LastName. If the JWT contains different attributes they should be added here. If the JWT sends Email, FirstName or LastName with a different attribute name, then it should be added here. The list of available values is propagated by the available user meta values.
Login URL: This field is provided by the authorization server. This is the URL the user needs to be redirected to to sign in.