Token expiration

[DLarsen]

It's not clear to me that the token expiration is reconciled with the token cache. As I understand it, msal can handle token refresh, but it seems that if we just hit the cache

[rayluo]

It is true that we did not even mention "token expiration", "token refresh" or "token cache" concept in this web app sample's README. We hope our sample can just do all the right things out of the box, so that our customers do not have to. As the way this sample currently being organized, the tokens would be persisted inside the token cache, which in turn is persisted inside a session; tokens are automatically reused, and refreshed when necessary.

Feel free to ask whatever question you want to know. We'd love to see your usage and scenario, and see what we can do.

[DLarsen]

It seems to me that if, for example, you had a session with a 30-day expiration, then you actually wouldn't any of the msal code during that 30-day period (unless the user manually logged out). So in that scenario it seems that the token expiration would not be honored at all.

I'm referring to this line: https://github.com/Azure-Samples/ms-identity-python-webapp/blob/master/app.py#L22

It seems that there needs to be something that checks tokens periodically so that the token reuse and refresh has a chance to execute.

[rayluo]

• If you were referring to user sign in, traditionally, once the user identity is verified (typically by authenticating username password to its backend), the web app front end can make its sole decision on how long it wants to keep the current session alive. This web app sample currently does not do anything special, we just let the default Flask behavior kick in.

• If you were referring to how this web app uses a short-lived access token to access another web api, this web app sample (and its underlying MSAL library) does take care of the token refresh, under the hood. Basically, we just use the web app's session as a token storage. Your such comment "It seems that there needs to be something that checks tokens periodically so that the token reuse and refresh has a chance to execute." is indeed happening already.

If I misunderstood your question, please help rephrase your question in the following form so that we know what you exactly want. "Repro steps 1... 2... 3... And then I observe XYZ but I expect ABC".

[DLarsen]

Thanks, Ray. My scenario is user sign in.

I understand your description under both bullet points. What it sounds like is that I'll just have to let our AD administrators and developers know how this works. The session expiration is separate from the token expiration, and therefore revoking a user's access to my web app could not necessarily be accomplished solely through AD.

[idg-sam]

PR #49