We are working on an internal SPA where the auth server is also our api server. The user logs in with username/password and our auth/api server responds with a token. We want to now handle the issue of an expiring token. When I look at the silent auth api parameters, I don’t see any parameter which indicates the requestor. Without this information, how does the auth server (in our case, also the api server) know how to generate the new user token? Is the silent auth grant even the way to proceed?
1 Like
The silent authentication is just a regular authentication request to the identity provider/authorization server where it’s stated that either the request can be completed without end-user interaction or it should fail automatically (without triggering any sort of action that would require the end-user and in such way be blocked by it).
The way a request such as this can be completed without requiring additional interaction is if an authenticated session already exists on the identity provider/authorization server side of things and the request is being done by the same user-agent that initially established such session (so it’s sending the correct session cookies).
In conclusion, the end-user associated with the request is dictated by the authenticated session if one exists. From the information provided it seems that the client application is sending a username/password to your server and then your server exchanges it with a token (possibly using a resource owner password credentials grant). If this is the case then that grant does not create any notion of authenticated session so the silent authentication would not be applicable.
The general recommendation for a SPA is to implement a centralized login experience where the user authenticates through the hosted login page (creating an authenticated session) and then perform subsequent requests through silent authentication until that session exists. In this way, the user actively authenticates once, but the application is able to get new tokens while the authentication session exists. See Call APIs from Client-side Web Apps for some reference documentation on the subject.
2 Likes
When session exists and my SPA is getting new access tokens from the hosted login page, how do you prevent malicious websites to get access token from the hosted login page too?
For example, could a cross-site request forgery attack be performed on the hosted login page to get the access token?
Your client only allows certain domains that you yourself have specified.