---
# System prepended metadata

title: JWT ID Token
tags: [FHIR_SkinLesionImageManagement]

---

---
title: JWT ID Token
tags: FHIR_SkinLesionImageManagement
---

Patient Portal JWT Token
===
<div style="text-align:justify;">This chapter describes the scheme of how authorization server (Patient Portal) generate JWT Token.

There are 2 JWT Tokens to be generated by Patient Portal:
- JWT ID Token: Token generated by authentication server to client whenever authenticate user, contains user and token information. The user information can be used for extent aplication such as client aplication user roles setting proccess.
- JWT Access Token: Token generated by authorization server to be used in the process of retrieving documents on the resource server. The JWT Access Token is designed to be integrated and validated by various resource server. This allows users to access resources on a diverse and scattered resource server.

JWT ID and Access tokens are public tokens that can be generated and shared by authentication and authorization server to clients. So it's specification and definition will be released publicly to make it easier for other developers to follow and take reference.
    
The purpose of JWT Token is to protect user information and its resources, so that the client or 3rd application can perform services on behalf of the user without obtaining visible user original information, and be able to access resources spread across various resource servers. 
</div>

## Table of Contents
[TOC]

## 1. Scenario
Patient A has an electronic health record on a resource server (eg: Google) and wants to give it's access to Tzu Chi Hospital. Then patient A must grant the electronic health record access to Tzu Chi Hospital, through the [process of granting resource access](https://hackmd.io/7t2dymxeRO634g2I9Easpg) on the Patient Portal. Furthermore, Tzu Chi Hospital can access patient A's electronic health record on the resource server (Google) using the JWT access token generated by the Patient Portal.

## 2. Purpose
- Provide authentication & authorization token for integrated healthcare web application
- Provide tokens for resource access on various resource servers
- Secure authentication and authorization JWT Token

## 3. Roles
- Token Requestor (HTTP Client): request token to token manager
- Token Manager (HTTP Server): generate and manage JWT tokens
- Token User (HTTP Client): using JWT Token to request web services / resources to resource server.
- Token Validator (HTTP Server): validate the token and provide RESTful API, web services, or resources that request by Token User (HTTP Client).
The request required to attach the JWT Token in its header so the Token Validator can validate the token whether the requester has permission to perform or get the result of the request.

There are two scenarios for Token Requester and Token User based on application types:
- If the process of generating and using tokens is carried out on the different types of applications. Such as web and window application. Then, Token Requestor and Token User are different.
    - Example: User requests github access token on Github web application, and uses it on Tortoise window application (Token Requestor: Github web application, Token User: Tortoise window application).
- If the process of generating and using tokens is carried out on the same type of application, the Token Requestor and Token User are the same.
    - Example: User request google access token on Google web application for use in Moodle web application (Token Requestor: Moodle web application, Token User: Moodle web application)

In this article, the mapping of Token's roles and workflow roles is:
- Token Requestor (HTTP Client): Client
- Token Manager (HTTP Server): Portal
- Token User (HTTP Client): Client
- Token Validator (HTTP Server): Cloud Healthcare Service and Server

## 3. Generating JWT Token workflow
### 3.1 Generating JWT Token to client web application workflow
When the user allows the client application to access user's data on a authentication serever, the authentication server will provide a JWT ID Token containing user information as a sign that the user has been authenticated.
![](https://i.imgur.com/hrrDdue.png)
<center><font size="1">Pic 1. Generating JWT ID Token to client aplication workflow</font></center>

### 3.2 Accessing granted resource using JWT Access Token workflow
When a resource grantee wants to access a resource granted to him on a client application, the authentication & authorization server will generate a JWT ID Token and an Access Token for the client application. The client will request access of resource using JWT Access Token to resource server. Then resource server will validate the token and response the document requested to the client.

![](https://i.imgur.com/QrvGgHK.png)
<center><font size="1">Pic 2. Get granted resource workflow</font></center>


The full workflow will be described bellow: [（Grantee get granted resource workflow）](https://hackmd.io/@jeshika/BkqsXQ3-i)
#### Prerequisite
1. [Create FHIR DocumentReference to index document on Patient Portal](/rk3qR60Zo)
2. [Create FHIR Consent for granting resource access](SJY4cGIZj)

Workflow roles:
- User: person who want to access resources that granted to him, such as patient or practitioner
- Portal: the party that generates tokens which can be used to access resources
- Client: 3rd party web or window application used to display resources
- Cloud Healthcare Services and Server: resource server where to store the resource
![](https://i.imgur.com/ZV4gCXH.jpg)
<center><font size="1">Pic 3. Get granted resource full workflow</font></center>

## 4. Token Content
### 4.1 JWT ID Token
:::spoiler JWT ID Token 
```gherkin=
{
   "jti":"155bf20e-5caf-415f-8078-5c896350c828",
   "iat":1615563526,
   "exp":1615563586,
   "nbf":1615563526,
   "aud":"https://https:203.64.84.150:58443/fhirtest1/fhir/",
   "client_id":"ClientWebsite01",
   "sub":"https:203.64.84.150:58443/portaltest1/fhir/PractitionerRole/misac.practitionerrole01", "iss":"https:203.64.84.150:58443/portaltest1/fhir/",
}
```
:::
### 4.1 JWT Access Token
Scope format: documenturl?action=Consent.provision.action
ex: https://203.64.84.150:58443/fhirtest1/fhir/Document/misac.document01?action=access
:::spoiler JWT Access Token 
```gherkin=
{
"scope":"https://203.64.84.150:58443/fhirtest1/fhir/Document/misac.document01?action=access",
  "client_id": "SLIUploadWebsite01",
  "token_type": "Bearer",
  "iat":1615563526,
  "exp":1615563586,
  "nbf":1615563526,
  "aud":"https://https:203.64.84.150:58443/fhirtest1/fhir/",
  "sub":"https:203.64.84.150:58443/portaltest1/fhir/PractitionerRole/misac.practitionerrole01", 
  "iss":"https:203.64.84.150:58443/portaltest1/fhir/",
}
```
:::

## 5. Reference
- [Smart on FHIR](https://smilecdr.com/docs/smart/smart_on_fhir_introduction.html)
## 6. Question
- What is the definition of JWT ID and Access token "sub" claim, is it used to record Portal user ID or Portal user's role?
- How is the definition of JWT ID and Access token "client_id" and "client_secret" claim?
     - How is the "client_id" validation process?
     - Is the token's "client_id" of an same application when accessed by different users have same value?