OAuth2 Proxy for Single Page Applications
As of this writing Single Page Applications (SPAs) have become mainstream and at the back-end the developers prefer to have set of general REST endpoints that can be utilized by applications where necessary. Having a coupled back-end for each and every application is becoming obsolete. However with these trends a new set of problems have arose and so does a set of solutions for them :).
Once the back-end and the front-end has been decoupled, a set of additional endpoints should be implemented for authentication and authorization purposes. Normally at enterprise level applications they hand over the authentication and authorization to a separate Identity and Access Management (IAM) system (think of this as a server that authenticate users and issue authorized tokens to access business endpoints). Once an IAM server is setup, then at SPAs they need to authenticate and authorize users against IAM server and should keep the access-token at the browser in order to be used when accessing business endpoints.
The recommended approach for SPAs in obtaining access-tokens in OAuth2 security protocol is the Implicit Grant Type flow. The concern is, Implicit Grant Type flow does not include client application authentication (because Implicit flow does not expect the client application to provide the client secret) when obtaining access token. That means there is no way for the IAM server to validate the application that the IAM server issuing the access token for, is an authentic client application. OAuth2 Authorization Code Grant Type flow mitigate this problem by requiring the client secret to be provided when requesting for an access token. Then again the client application’s client-id and client-secret should be kept at the browser side. However in any manner making access token invisible for end user is not possible for SPAs where there is no coupled back-end.
OAuth2 Proxy for SPAs
So the SPA developers tend to implement a coupled back-end part for their SPA to adopt OAuth2 Authorization Code Grant Type flow. Then the application client ids and secrets can be kept at the back-end (probably in a property file), so does the access tokens (probably in a database). When the SPA needs to access a business endpoint the SPA just have to do an AJAX call to a particular endpoint on its own back-end (say /api endpoint). Once that endpoint receives a request, it would retrieve the access token from the database storage and add it at the Authorization header, execute the request, get the response, send it back to the SPA.
Instead of implementing above described back-end for each and every SPA, making it general and usable with any SPA simply with some config changes would reduce substantial amount of effort at SPA development. As per the above explanation you can see that this act as a proxy where all the requests from the SPA should go through this back-end part. This is called an OAuth2 Proxy for Single Page Applications.
Making OAuth2 Proxy for SPAs Stateless
Once deployed this OAuth2 Proxy can be used by several SPAs in the same enterprise. Here maintaining a database to keep the access tokens of all the SPAs is bit cumbersome. So a way to make the proxy stateless without maintaining any database would be much more appealing. This can be achieved by encrypting the jwt (access token, id token, and etc. received at the authorization step) and putting it in a cookie and sending it to the browser.
So when SPA do an API call via OAuth2 Proxy, OAuth2 Proxy receives the encrypted cookie, decrypt it, and add the access token at Authorization header, execute actual API request, get the response, and send the response to the browser.
An implementation of the above described OAtuh2 Proxy for SPAs can be found in the this repo. This implementation is bound to the WSO2 Identity Server as the OAuth2 IAM server. A sample SPA application that utilises this OAuth2 Proxy implementation can be found in this repo. A sample demo application has been implemented using ReactJS and React-Boilerplate. The deployment and implementation details will soon be included in corresponding repository’s README.md files.