UserManager Methods

signinRedirect

In this variation the browser leaves your page entirely, then comes back to it after the user has successfully authenticated. This always works to get user information.

The URL that the user will be sent back to is the redirect_uri given when constructing the UserManager on which you call signinRedirect. If signinRedirect is given a parameter that has a state property, the value of that property will be reconstructed later on the User object.

The page that loads at redirect_uri can generate a User by reconstructing the UserManager and invoking signinRedirectCallback with the query string that came from the authentication server. The state property on the User object will be the state property of the parameter given to signinRedirect.

signinRedirectCallback causes the User object to be generated, but the promise it returns resolves to null, so the object must be retrieved by other means. If User generation fails, the promise will reject with a non-null error.

signinSilent

In this variation the library generates a hidden iframe into which the browser loads a URL on the authentication server, then redirects the iframe to your page. This only works to get user information when the authentication server is able to recognize an active session for the browser without any user interaction.

The URL that the iframe will be redirected to is the silent_redirect_uri given when constructing the UserManager on which you call signinSilent. If signinSilent is given a parameter that has a state property, the value of that property will be reconstructed later on the User object.

The page that loads at silent_redirect_uri cannot generate a User itself; the iframe is hidden and temporary, so that probably wouldn't be useful anyway. What it can do is trigger the generation of a User in the parent page by reconstructing the UserManager and invoking signinSilentCallback with the query string that came from the authentication server. The state property on the User object will be the state property of the parameter given to signinRedirect.

signinRedirect causes the User object to be generated, but the promise it returns resolves to null, so the object must be retrieved by other means. If User generation fails, the promise will reject with a non-null error.

Retrieving the User object

Since the methods that trigger generation of a User object do not return that object (or a promise that resolves to that object, the generated User object must be retrieved by one of these means

1. The getUser method on UserManager returns a promise that resolves to a User object. This can be done any time after generation, and must be done again if other User objects are generated later. If getUser is called before generation, it may resolve to a stale User with invalid tokens.

2. The events.addUserLoaded method on UserManager takes a callback function as a parameter, and thereafter whenever a User is generated the callback will be invoked with that User as a parameter. This can be done any time before generation, and does not need to be done again if other User objects are generated later (the same callback will be invoked again).

User validity

The library makes some attempt to save user information where it can be reloaded without making network requests. If getUser is called before triggering generation it might return a stale User with expired access tokens. If you get a User from getUser before triggering generation, do not assume the access tokens are valid. There are at least 2 ways to ensure that you don't use an expired User:

1. Check the expired and expires_in properties on the User object. These can tell you if the user has expired, but cannot tell you if the user has logged out in another tab and thereby invalidated the tokens.

2. Just do a signinSilent before you even think about calling getUser. If it resolves, the User you get immediately after is valid; if it rejects you need to do an interactive login e.g. with signinRedirect.

The querySessionStatus method on UserManager may be able to give complete status information, but it performs a callback to silent_redirect_uri that has a very different query than signinSilent.