Hi all,
I believe, in relation to the OAuthInfo.flowType changes described in the release notes for 4.28, the IdentityManager is now defaulting to using an 'authorization-code' instead of 'implicit' flowType, where 'implicit' means using a one-step OAuth flow, which is no longer recommended.
What we have in our application is we are saving the state of authentication (from IdentityManager.toJSON()), and when the application initializes, we restore that state (using IdentityManager.initialize(<json>)).
With the `implicit` workflow, we get a token that is valid for two weeks by default, and that gets output with the identity manager state and restored when we re-initialize the IdentityManager with that state. With 'authorization-code' flowType, the token that is saved in the IdentityManager's state is a 30-minute short-lived token. My understanding is that the 'authorization-code' flowType is effectively using what has been referred to as a Server-based workflow, where a long-lived refresh token obtained from the initial OAuth authentication is used to obtain short-lived credentials, and the short-lived credentials are used to access secured resources. I can see this happening with the IdentityManager, where it is saving a data object that contains the refresh token in the browser's session storage (and this is the token that has the default two-week expiration), and I can see the requests that use this refresh token to obtain the short-lived token. So far so good.
The problem I've run into is that the refresh token does not get output with the IdentityManager's state data, and the data object in the browser's session storage is gone once the user closes/re-opens the browser. We'd like to be able to persist the authenticated state in a seamless way, and I'm not certain what the best/recommended approach would be.
My thought at the moment is that we can securely persist the data object with the refresh token in the browser's session storage (i.e., in a user setting that we'd store encrypted server-side in our application). Upon re-initialization of our application, we would restore the same data object in the current browser's session storage, then re-initialize the IdentityManager's state as we have already been doing. If the short-lived token is expired, then the identity manager will automatically detect and use the refresh token from the session storage. I have tinkered a bit, and this seems to work...does it sound reasonable? Is there a better way to do this?
