Usage: SSO Single Page Application Alt (All Code Runs in Browser) Requirements

Project Title	Campus API Gateway
Target Release
Epic
Document Status	DRAFT
Document Owner
Document Sign-Off
Subject Matter Expert(s)
Technical Expert(s)

Background & Business Value

A new architectural style of applications is to host all the code which runs the application in an unsecured location (ie. AWS S3 Bucket). A website url will pull files directly from the unsecured location and javascript will run within a browser to load up the entire application. This is one of the approaches to implement Single Page Applications (it doesn't have to be done this way).

In this architecture, the backend code that would normally make up the applications is open to the internet and runs solely within the end users browser. Because of this, it cannot safely store the Application Accounts password (Service Accounts password). To handle this scenario, the OAuth implict grant was created. A prerequisite for using an implicit grant is that the Application Account (Service Account) must pre-register a callback url with the OAuth Server. This takes the place of the password. When the web browser app redirects to use the SSO login, it must send across the applications client_id and the expected redirect_uri for that client_id. Only if the redirect_uri matches up with the previously registered value will an Authroization/Access Token be created.

Goals

All goals of Usage: SSO Enabled Application w/ User to Resource Server Requirements
Support unsecured code base SPA applications.

Out of Scope

Same as Usage: SSO Enabled Application w/ User to Resource Server Requirements

Assumptions

Same as Usage: SSO Enabled Application w/ User to Resource Server Requirements
Campus IdM will support implicit grant.

Requirements

Must meet all requirements of Usage: SSO Enabled Application w/ User to Resource Server Requirements

Ticket(s)	Title	User Story	Priority	Notes
	Access Tokens used in Browser	As an Application Developer, the authentication/access tokens generated by the authentication system will need to be used from the browser.	MUST HAVE	Will need to support implict grant. Will need to inform Apigee the internal Apigee `client_id` for the given Service Account `ucsbNetId`. Can retrieve new access tokens using hidden requests.

User Interaction, Design & Architecture

Service Architecture for OAuth Token (PowerPoint)

Sequence Diagram for OAuth Token (WebSequenceDiagrams Link)

Service Architecture for OAuth JWT (PowerPoint)

Sequence Diagram for OAuth JWT (WebSequenceDiagrams Link)

Examples and References

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question Outcome Decision Date

Since we may need to flow the SSO Login Form through the Apigee proxy, maybe the endpoint on Apigee should match the endpoint on PingIdentity. So, instead of /oauth/generate use /as/token.oauth2 and instead of /oauth/authorize use /as/authorization.oauth2. Just generally make the flow through endpoint on Apigee be /as/.

If the Login Form from the OAuth server is gzipped when it returns to the Apigee server. Will Apigee be able to unzip/deflate the contents, modify the contents, and gzip the contents back up before forwarding the results on to the Browser?

Need to research