0👍
I have been thinking about this for awhile – I’m currently working to build an angular application that accesses a REST API built in node. In keeping with REST, I shouldn’t be maintaining a session, and instead should be passing some user/password detail along with each request.
Now obviously, a lot of API’s are happy to stick with some sort of basic authorization or api keys thereby avoid oauth2, but I wanted to log on with google/facebook, so a certain amount of token wrangling was going to be required. The particular flow I’m using is this –
-
User accesses the angular application. As they are not logged in, they will be given a log in page with a choice to login with google/facebook.
-
Assuming they click to log on with google – the link sends a request to my node server, with starts the google authorization flow by redirecting the user to googles sign in page.
-
They give access to the app/log in – which then redirects back to the node server, which acquires the oauth2 token from google. The node servers then stores this token for the particular user.
-
Finally the node server redirects back to the angular app along with the token in the header. This token is stored the browser session, and is used when the app makes an api request. If the api request receives a valid token it responds in kind, otherwise it passes an error and the angular app notes this and redirects to the login page with some sort of relevant error notice.
If you’re opening the API up to third parties, you will probably need to do a bit more work, but it is not something I have considered too much at the moment.