Healthcare Data Exchange: Authorization and Authentication
Overview
This course provides a comprehensive review of health data security and privacy standards, frameworks, and protocols. This course uses Meld to provide learners with hands-on activities using data querying and the SMART-on-FHIR Launch framework. Upon successful completion of this course, learners will be able to: understand the legal frameworks guiding security and privacy requirements in healthcare; describe how data exchange works using APIs; understand authentication and authorization protocols and frameworks; describe how UDAP and its specifications play a role in the future of health data exchange; query Meld for synthetic patient data using Hoppscotch.io; register and launch a SMART-on-FHIR application.
Overview of Course
This course provides a comprehensive review of health data security and privacy standards, frameworks, and protocols. This course uses Meld to provide learners with hands-on activities using data querying and the SMART-on-FHIR Launch framework. Upon successful completion of this course, learners will be able to: understand the legal frameworks guiding security and privacy requirements in healthcare; describe how data exchange works using APIs; understand authentication and authorization protocols and frameworks; describe how UDAP and its specifications play a role in the future of health data exchange; query Meld for synthetic patient data using Hoppscotch.io; register and launch a SMART-on-FHIR application.
Subject: Health, Medicine and Nursing, Information Science
Level: Community College / Lower Division, College / Upper Division, Graduate / Professional
Material Type: Activity/Lab, Diagram/Illustration, Full Course, Lesson Plan, Reading, Student Guide
Author: Interoperability Institute
Date Added:
License: Creative Commons Attribution Non-Commercial No Derivatives
Language: English
Media Format: Graphics/Photos, Text/HTML
Healthcare Data Exchange History
Learning Objectives:
After completing this lesson, you will be able to:
Understand the legal framework that guides patient privacy and security
Describe Transport Layer Security
Security and Privacy
HIPAA Right of Access
In 1996, the Health Insurance Portability and Accountability (HIPAA) Act was established to protect patients' medical records. HIPAA distinctly identifies rules for maintaining privacy and security of the patients' protected health information (PHI) record. The Privacy and Security rules outline very clear expectations for how to ensure the patient record is kept confidential and secure.
HIPAA’s Privacy Rule puts the patient in the driver’s seat of their records by allowing them to control the access and use of his or her personal information. Covered entities, such as health plans or providers, must provide patients, their representatives and approved third parties with access to their protected health information through designated record sets. A designated health record set will include medical records, coverage, claims, adjudication, or case management records maintained by or for the covered entity or health plan.
Patients and/or their legal representatives can submit via writing or electronic format a copy of their PHI from any covered entities. If submitting a request for a third party to access their record, patients will sign a waiver for each individual entity they would like to be able to view their health data. This portion of HIPAA also requires that covered entities must provide patients with three different methods of obtaining their health data to avoid delays in patient access—physically going into the provider’s office, technological route (such as emails or mobile apps), or physically mailing to the patient’s address.
Covered entities are required to verify that the request has come from the patient, but the method and type of verification process is left to the discretion of the covered entity as long as the selected verification process does not inhibit or delay the patients access to the PHI.
As technology has progressed, the use of application programming interfaces (APIs) has become increasingly common in the healthcare landscape. These APIs must abide by the rules laid out by HIPAA, meaning that they must provide individuals with an electronic request that can approve or deny the electronic transmission of PHI. These regulations have led to appropriate privacy protections and data security safeguard being implemented within the APIs and other healthcare applications.
The following are key areas for privacy consideration when implementing APIs in healthcare:
- Provide patients electronic access (e.g., an electronic form within a patient portal) to request transmission of PHI in accordance with the HIPAA Privacy rule.
- Enable technology that will allow individuals to choose what specific types of health information (e.g., medication lists, allergies) they want to share if they are requesting the records be provided to a third party.
- Provide clear and easily accessible options to revoke third party access permissions.
Security Considerations
Security Considerations
The Security Rule addresses the protection of patient PHI from unauthorized internal or external access including administrative, technical, and physical safeguards. The utilization of APIs for data sharing is becoming more prevalent with the adoption of the HL7 FHIR standard. When implementing APIs in healthcare, there are multiple key areas for security consideration.
Encryption-Use - TLS with strong cipher suites to help protect the health information in transit via the API from the EHR to the third-party. TLS will be discussed further below.
Input Validation of API Calls - Assure that arbitrary code cannot be executed as well as assuring that the input meets that size/shape/type required.
Access Controls
Identity Proofing- The process of attributing an online identifier with a person, standards like 800-63A cover these requirements in detail.
Credentialing- Also develop technical and administrative policies that explain how to issue credentials to individuals that will grant them access to their health information.
Verification of Access controls Auth and Auth
Strongly consider implementing risk-based authentication controls, which is a method of applying varying levels of stringency to the authentication process, that flow from the organization’s security risk assessment. The controls, and are commensurate with the type of data, level of sensitivity of the information, and user type.
Create systems with technical authorization controls that are flexible enough to support individual privacy preferences that are can limit API use, access, or disclosure based on what is necessary to satisfy a particular purpose or carrying out a function.
Service Provider Security- Evaluate any service provider’s infrastructure, security practices, and technical capabilities for hosting implementations of APIs and apps that store, handle, and access health information. This assures that the service provider will appropriately safeguard the health information in a way that is consistent with the organization’s security policy.
Data Integrity-Put in place data integrity protection controls that can detect when unauthorized alterations are made to health information made accessible through the API.
Patient Access Security-Ensure that EHR patient portals that interact with the API are secure and protected against known vulnerabilities that attackers could exploit.
TLS
Transport Layer Security (TLS) is a secure transport and session protocol that provides confidentiality to web traffic using cryptography. TLS is used to create secure a communications channel for client-server applications by encrypting online traffic in flight and like confidential data communicated between a user’s web browser and a webserver.
Communication/Data Exchange
Learning Objectives:
After completing this lesson, you will be able to:
Describe RESTful API architecture
Understand how APIs and applications communicate
Understand the basics of GraphQL and how it is used by FHIR
What is an API?
What is an API?
An API is an application programming interface where the interface is a shared endpoint for computer systems to exchange information. Web APIs allow communication between applications and systems over the internet to access and share data.
APIs are typically implemented according to a set of standards, such as REST or GraphQL which are described in the following sections.
HTTP Protocol
HyperText Transport Protocol (HTTP) is the foundation of data exchange on the web. Clients and servers communicate by exchanging messages. HTTP is a client-server protocol. The client such as a web application sends a message, which is called a request, and receives an answer from the server, which is called a response.
HTTP requests and responses are structured in a similar manner. This structure includes:
A start-line that describes the request method to be implemented or its success/failure status.
An optional set of headers specifying the request or describing the body of the message.
An optional body containing data associated with the request
What is REST?
What is REST?
The term ‘REST’ stands for “representational state transfer”, a software architectural style created to guide the design and development of web architecture. REST is an API pattern that has become widely popularized over the last decade. The REST pattern standardized the way that APIs are planned, configured, built, and managed. A RESTful architecture style promotes interoperability between systems on the Internet by standardizing the method of communication. There are several key components of RESTful APIs including resources, endpoints, request methods, and response status codes.
Resources
A resource is defined as any complex data type. For example, a patient record is a type of resource.
Endpoints
When an API is interacting with another system, the point of communication is an endpoint. An endpoint is a URI that enables an API to access another server. The endpoint is the point at which the API connects with the application server. When a request is made, the API endpoint provides a response.
Request Methods
Client applications can interact with a server using HTTP request methods. These methods include:
GET – used to read or request a resource from the server
POST – used to create a new resource in the server
PUT – used to update existing resources in the server or create a resource if the resource does not already exist in the server. In more technical terms, if the request URI refers to an existing resource, the request will modify the version residing in the origin server. If the request URI does not point to an existing resource, the origin server can create the resource with that URI.
[Insert example of a PUT request here]
DELETE – used to remove a resource from the server
Response Status Codes
A response status code indicates the result of a client request. Common HTTP response status codes include:
- 200 OK
- 201 CREATED
- 204 NO CONTENT
- 400 BAD REQUEST
- 401 UNAUTHORIZED CLIENT REQUEST
- 403 FORBIDDEN
- 404 NOT FOUND
- 500 COULD NOT PROCESS REQUEST (Umbrella for errors)
CRUD Operations
CRUD
CRUD stands for CREATE, READ, UPDATE, and DELETE. The CREATE command creates new records through INSERT statements, similar to a POST command. The READ command reads data based on input parameters. The UPDATE command modifies records without overwriting them. The DELETE command deletes records where specified.
REST is an API architecture while CRUD is a cycle for maintaining records. CRUD can be mapped to HTTP protocols, as can resources in RESTful architecture.
GRAPHQL
GRAPHQL
What is GraphQL?
GraphQL is a query language for APIs that allows for contractual interaction between a client and server.
GraphQL vs. REST
REST APIs typically require loading data from multiple URLs, also known as endpoints. In contrast, GraphQL APIs enables client applications to retrieve all necessary data in a single request. GraphQL APIs are organized by type and field rather than endpoints, allowing clients to specify the type of data they wish to receive from the server. GraphQL queries access the properties of singular resources and simultaneously follow references between resources. A benefit of using GraphQL is its ability to return predictable results, along with its clear and standard versioning guidelines.
Using GraphQL with FHIR
Currently, GraphQL is not a formal standard and the language is still under development. However, the GraphQL interface can used as simplified interface in front of a standards-compatible RESTful API.
A GraphQL query must start by selecting a resource type and a search criteria:
[base URI]/[Type]/[id]/$graphql
Authentication and Identity
Learning Objectives:
After completing this lesson, you will be able to:
Describe Authentication and Identity
Understand the protocol of basic authentication
Identify different forms of authentication
Understand how OpenID Connect utilizes authentication
Understand how Security Assertion Markup Language (SAML) utilizes authentication
What is Authentication?
What is Authentication?
Understanding the meaning of identity is vital to understanding what authentication is and how it works. Identity is a single body or bodes of information which can provide a unique value to identify a person, organization, or entity. Authentication is the process of verifying the identity of a user.
There are various forms of authentication that can be used depending on the circumstance of the situation. The simplest form of authentication is known as basic authentication. This is a method for an HTTP user agent, such as a web user, to provide a username and password when making a request to a server.
Basic authentication will generally follow the steps outlined below.
Steps on the Server Side
After receiving an unauthenticated request, the server will want the user who submitted the request to authenticate themselves. To do this, the server will send an HTTP 401 Unauthorized Status line response and a www-authenticate header field to the user.
- www-authenticate: basic realm = “User Visible Realm”
Steps on the Client Side
When a user would like to authenticate themselves to the server, it may use the authorization header field. This field would be constructed as follows:
- The username and password are combined with a single colon
- The resulting string is encoded by an octet sequence
- The resulting string is encoded by using a variant of Base64 (+/- with padding)
- The authorization method and a space is then added to the beginning of the encoding string
Types of Authentication
Types of Authentication
There are many different types of authentication. There are several factors that are considered when selecting the appropriate authentication type, such as security needs, how the user will access the server, how many users the server will have, and what may be required by law—depending on the content within the server. Here are a couple of authentication methods that can be chosen based on the above factors.
Password-Based Authentication
The most common form of authentication. The user will input a unique ID or username which will identify which user is trying to access the server. Then the user will input a key or password which confirms the identity of the user.
Certificate-Based Authentication
Digital certificates are used to identify the user trying to access the server. The digital certificate contains the digital identity of the user, including the public key and the digital signature of the certificate authority. Digital Certificates prove the ownership of a public key, therefore indicating the user can have access to the server.
Computer Recognition Authentication
Computer recognition verifies the user’s identity by confirming that they are using a particular device. This form of authentication utilizes a software plug-in on the user’s computer the first time that they log in, it will leave a cryptographic device marker which will be for authentication in the future.
Biometric Authentication
Unique biological characteristics of individual users are verified using this process. Common forms of biometric authentication methods include facial recognition, fingerprint scanners, speaker recognition, and eye scanners.
Token-Based Authentication
Users enter their credentials once and receive a unique encrypted string of characters, known as a token. Users can then use the received token to access protected systems instead of needing to reenter their credentials.
Multi-Factor Authentication
This method of authentication requires two or more independent ways to identify users. Examples include all of the authentication methods above, as well as, user phone numbers, captcha tests, or applications specifically created for multi-factor authentication.
There are a number of ways for a system to identify users. In addition to the methods discussed above, the three most common ways for a system to identify a user include:
A password or a PIN
A smartphone application (ex: Duo security)
A fingerprint or facial recognition
Security Assertion Markup Language (SAML)
Security Assertion Markup Language (SAML)
SAML is an open standard that enables Single Sign-On (SSO). This provides users with the ability to seamlessly access multiple applications, websites, or servers while only using one set of login credentials. As an XML-based standard, SAML is quite flexible. Single implementations can support SSO connections with many different federation partners utilizing SAML.
SAML holds the main position for federated identity deployments and has been deployed in thousands of large enterprises, government entities, and service providers.
SAML will generally follow the steps below (assuming an IP named Identity+ and a service provider Imaginary Company):
- A user tries to log in to Imaginary Company through their web browser
- Imaginary Company responds by generating a SAML request
- The web browser server redirects the user to the SSO URL—Identity+
- Identity+ parses the SAML request and authenticates the user—this can be done using several authentication methods, the service provider would decide which one. Once the user is authenticated, Identity+ generates the SAML response.
- Identity+ returns the encoded SAML response to the web browser.
- The web browser sends the SAML response to the Imaginary Company to verify.
- If Imaginary Company successfully verifies the response, the user will then be logged into Imaginary Company.
Authorization
Learning Objectives:
In this section you will learn about:
- The purpose of Authorization.
- The process that occurs during Authorization.
- How Authorization is implemented through OAuth 2.0.
- OAuth 2.0 roles and flows.
What is Authorization?
What is Authorization?
Authorization is a process that determines what a user can and cannot access after they have completed the authentication process successfully. It verifies whether access is allowed through an established set of policies and rules where at times, an Access Token is transmitted to the client if the authorization is approved. Not all authorization requires an Access Token. If an individual is not authorized for a specific resource, even if they have proven their identity, they can still be denied access.
This process is generally governed by OAuth 2.0 in web applications, which will be discussed in the implementation section that follows.
Example
An employee is looking receive authorization for a specific file that contains protected information and data. Once they have successfully completed authentication, they then begin the authorization process by providing their credentials to the file owner through a server that is typically separate from the resource server. The resource owner decides on whether that employee has the appropriate credentials and need for that file and grants them an Access Token that allows them to access the file on a different server under a new unique set of credentials in which the only protected file they will have access to is that one specifically. The employee is then allowed to utilize that file, and that file only.
Implementation
OAuth 2.0
OAuth 2.0 is a protocol that allows a user to grant an external or third-party website or application access to a client of that user’s protected resources, without necessarily revealing their long-term credentials or even their identity in some instances. This process introduces an authorization layer that separates the role of the client from that of the resource owner.
Within the process, the client begins by requesting access to resources that are in control of the resource owner and is hosted by the resource’s server. The client is then issued a unique set of credentials different than those of the resource owner to access the resource.
Instead of using the resource owner’s credentials to access protected resources, the client will obtain an access token, which is typically a string denoting a specific scope (permissions represented by the access token), lifetime (how long the client will have access), and other attributes that are tied to the granted access.
An OAuth 2.0 flow contains the following four roles within the process:
- Resource Owner: Entity that has the power to grant the access to a protected resource.
- Client: Application requesting access to a protected resource on behalf of the Resource Owner.
- Resource Server: Server that is hosting the protected resources and the API that the client wants permission to access.
- Authorization Server: Server that authenticates the Resource Owner and then transmits access to tokens after getting proper authorization. In this case, AuthO.
OAuth 2.0 also defines four flows to receive an Access Token. These flows are defined as grant types and deciding which one is suited for an individual’s case depends mostly on the application type that is being used. The grant types are:
- Authorization Code Flow: used by Web Apps executing on a server, also used by mobile apps using the Proof Key for Code Exchange technique.
- Implicit Flow with Form Post: used by JavaScript-centric apps executing on the user’s browser.
- Resource Owner Password Flow: used by highly trusted apps.
- Client Credentials Flow: used for machine-to-machine communication.
The Future of Healthcare Data Exchange
Learning Objectives:
- The status of healthcare data exchange (maybe rename technical barriers?)
- Overview of UDAP
- Why UDAP is important for future growth in data exchange
- Where UDAP is currently being used
- The specifications within it (summary)
- JWT-Based Client Authentication
- Trusted Dynamic Client Registration
- JWT-Based Authorization Assertion
- Certifications & Endorsements
- Tiered OAuth
6. Levels of security found
7. Compare/Contrast SMART-on-FHIR
What is the status in healthcare data exchange?
Currently, HL7 FHIR has some technical barriers that make it difficult for FHIR to scale. FAST (FHIR at Scale TaskForce) has determined that there are six main issues that need to be addressed.
1. Directory Services
- Inability to find FHIR endpoints and its associated capabilities/characteristics
- No directory or some form of maintenance for endpoint information or validation
- Need the ability to restrict discoverability of specific endpoints
2. Identity
- Unique identifies are not meaningful outside the organization they come from
- ‘Cross-walks’ (small orgs that exchange patient and provider rosters to make a common key) are not scalable
- Need a minimum amount of data
- Response, including error messages, needs to consider privacy
- Overlaps, duplicate records, and incorrect matches could require legislation beyond that of technical recommendations
- Enable identity cross-walks
3. Security
- Inability to ensure that the requestor has been properly authenticated and has the authorization to view and use the data
- It is not clear how to scale and administer Open Authorization
4. Testing, Conformance, & Certification
- Requirements formatted for ease of what should be tested and certified
- Lack of minimum baseline of FHIR conformance
- Require validation through automated tooling
- Use test driven development
- There is currently no governing body to grant
5. Versioning
- Need to be able to support multiple versions of FHIR
- Importance of a capability statement to determine functions
6. Scaling
- Various interoperability models
- Inconsistent response time and predictability
- Difficulties in linking patients and their records
- Performance issues as FHIR becomes adopted
What is UDAP?
Unified Data Access Profiles (UDAP) are building blocks to improve the scalability of the FHIR ecosystem guided by the ONC’s FHIR at Scale Taskforce’s Security Tiger Team (FAST: Scalable Registration, Authentication, and Authorization for FHIR Ecosystem Participants Luis Maas, MD, Ph.D. May 28, 2021). By extending the OAuth 2.0 and SMART App Launch frameworks, UDAP supports secure and scalable workflows for applications that implement the authorization code or client credentials flow.
Client Authentication
JWT-Based Client Authentication
Implemented as an extension to the OAuth 2.0 framework, a client application constructs, and signs a JSON Web Token (JWT). This token is used by the client application as an Authentication Token, which is included in its request for an access token as a client assertion to authenticate itself to the Authorization Server’s token endpoint.
The client app first directs the end-user to the Authorization Server’s authorization endpoint to obtain an authorization code. The client app then creates an Authentication Token, which is included in the app’s request to the server’s token endpoint. This gives the client control of a private key and provides the digital certificate needed to validate the signature. The Authentication Token is a signed JWT and includes the following key-value pairs:
Iss: contains URI of the Client Token Service
Sub: the client ID issued by the authentication server to the client application
Aud: token endpoint URI of the authorization server
Exp: token expiration time expressed as seconds
Iat: issued at time expressed as seconds
Iti: token identifier used to identify token replay (occurs when a hacker listens to a secure network communication, intercepts it, and fraudulently delays or resends it to misdirect the receiver into doing what the hacker wants)
The client app uses this token to authenticate itself in its request for an access token from the Authorization Server. The server validates the digital signature on the Authentication Token and returns a token response if the request is approved.
Dynamic Client Registration
Dynamic Client Registration
UDAP extends OAuth2 and OpenID Connect and lesser utilized aspects of related RFCs to leverage trusted digital certificate authorities to build a trust community. This eliminates the need for every FHIR endpoint to manually register every client application by enabling the automated reuse of OpenID credentials or digital certificates in JWT (JSON Web Token) based authentication. Authorization servers requested by client applications confirm UDAP support through metadata and direct the client to register on the server.
Dynamic Client Registration identifies and dynamically registers trusted client applications that have been pre-screened by certificate authorities. Using Trusted Dynamic Client Registration, the client directs the user to the server’s authorization endpoint to obtain an authorization code. The client then creates a signed JWT. The JWT provides the metadata required for registration, establishes client app control of a private key, and provides the digital certificate needed to validate the signature and establish trust.
The client app requests registration by submitting this token to the Authorization Server’s authorization endpoint, which validates the request. If the request is approved, the Authorization Server returns a response including the Client ID issued by the server for the client app to use.
Open Authorization
Tiered OAuth for User Authentication
UDAP Tiered OAuth for User Authentication provides another way to authorize users. This method leverages Identity Providers (IdP) and existing credentials to determine authorization decisions for resource holders. In this system, when a client application requests authorization or authentication from a resource holder, the resource holder requests user authentication from a trusted upstream IdP and uses the authentication request information and IdP’s information to deny or accept the client application. This reduces information leakage as client apps or third-party apps are not solely responsible for authentication.
TLS Client Authentication
TLS Client Authentication
This client authentication protocol can be used with any OAuth 2.0 grant mechanism where a client app authenticates the Authorization Server’s token endpoint by transmitting a certificate during the TLS handshake to obtain an access token. This includes authorization code flow, client credentials flow, or other extension grant flows utilizing the token endpoint by client apps. Before granting an access token, the Authorization Server validates the digital signature on the client certificate during the handshake and evaluates the trust chain for this certificate.
UDAP & SMART-on-FHIR
Currently, FHIR standards require that client applications and payers support the standalone launch sequence of the SMART App Launch framework for user authorization and client authentication. UDAP Dynamic Client Registration allows client applications and servers to automate the negotiation of trust and technical requirements without manual intervention.
UDAP can be used to extend OAuth 2.0 and the SMART App Launch Framework for consumer-facing applications. Client application operators must register each application with the Authorization Servers identified by the FHIR servers that they will exchange data with. The Authorization Servers should support dynamic registration (specified in the UDAP Dynamic Client Registration Protocol).
Authorization Process:
Client applications must follow the OAuth 2.0 authorization code grant flow, as extended by the SMART App Launch Framework, to obtain access tokens to access FHIR resources. Client applications will request an authorization code per the SMART App Launch Framework, but are not required to include a launch scope or launch context requirement scope. Additionally, client applications and servers may choose to support UDAP Tiered OAuth for User Authentication to allow cross-organizational and/or third party user authentication.
In the next section, a technical activity demonstrates how to register and launch a SMART application using some of the authentication and authorization frameworks discussed in this lesson.
Glossary
Access Token – Contains the security credentials for a login session and identifies the user, user groups, user privileges, and sometimes a specific application
API – Application Programming Interface
Authentication - A mechanism to verify the identity of a user
Authorization - A mechanism to determine the level of access of a user to system resources
Covered Entities – A health care provider, a health plan
CRUD – Create, Read, Update, Delete
Encryption – The process of encoding information
FHIR – Fast Healthcare Interoperability Resources
HIPAA – Health Insurance Portability and Accountability Act
HL7 (Health Level 7) – International standards for the transfer of clinical and administrative healthcare data between software applications
HTTP – Hyper Text Transfer Protocol
Identity Proofing – The process of verifying that the identity of a person
OAuth – Open Authorization
ONC – Office of the National Coordinator for Health
PHI – Protected Health Information
REST – Representational State Transfer
SAML – Security Assertion Markup Language
SSO – Single Sign-On
TLS – Transport Layer Security
UDAP – Unified Data Access Profiles
XML – Extensible Markup Language
Sources
Healthcare Data Exchange History:
https://www.healthit.gov/sites/default/files/privacy-security-api.pdf
https://www.hl7.org/fhir/security.html
https://www.techsoup.org/support/articles-and-how-tos/introduction-to-transport-layer-security
Communication/Data Exchange:
https://www.healthcareitnews.com/news/what-you-need-know-about-healthcare-apis-and-interoperability
https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages
https://stevenpcurtis.medium.com/rest-vs-crud-ca5522bf3fc3
https://stevenpcurtis.medium.com/endpoint-vs-api-ee96a91e88ca
http://hl7.org/fhir/r4/graphql.html
https://asymmetrik.com/getting-started-with-fhir-and-graphql/
Authentication and Identity:
What is: Multifactor Authentication (microsoft.com)
https://auth0.com/blog/how-saml-authentication-works/
https://www.pingidentity.com/en/resources/client-library/articles/saml.html
Authorization:
https://auth0.com/docs/authorization/protocols/protocol-oauth2
https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
The Future of Healthcare Data Exchange:
http://hl7.org/fhir/us/carin-bb/STU1/Authorization_Authentication_and_Registration.html
https://docs.google.com/document/d/1HgOlUWMEsZHBChuP4DACRka4ap2S8UwSTkAz4oY6bCo/edit