Refresh Tokens, Expiry of Tokens, and long-term operation provisioning

Question

My knowledge of OpenId Connect is growing but limited, but I have a particular issue I am seeking advice on.

Our application is being updated to support OpenId Connect presently (we shall be using Azure AD as our primary identity provider). The general authentication flow seems straightforward enough.

A very significant issue for us is that one of the operations that our system allows for is "report generation" via a "report subscription" mechanism. In other words, a user can set up a report and get it emailed to them periodically (eg. daily, weekly, monthly, yearly etc).

The key point is that this subscription is long term and persistent.

The nature of the report subscription "generator" means it essentially needs to "impersonate" the user who owns the report in order to run the report, because different users are limited to different slices of data in the database (eg. by department).

In the context of OpenId Connect, I am struggling to determine what the correct approach should be for dealing with this kind of "long term" situation. These reports could sit there for literally years, and be expected to run. They also run without further user involvement, so the idea of re-prompting for credentials is not really a practical one.

It does not feel like a "typical" use of an access token and a refresh token, even if our application were to be the provider of such tokens. Azure AD certainly imposes a maximum refresh token expiry of 90 days, now non-configurable.

Can anyone advise what the best practice approach is for these kinds of situations?

Answer 1

This is scheduled or event based job processing, where the job needs to iterate over users to get specific data sets. If the job needs to interact with remote APIs then an access token is needed, and the Client Credentials grant would be used, to represent the identity of the job.

Scopes can be useful here, to limit the privileges to just those needed. Eg the job might get a token with a report_generation scope that entitles it to operate on all users, but only to access reort related data. An interesting building block is the use of Prefix Scopes where you get a token with a scope such as users-123, that can only access data for that user.

Either way, if APIs are involved, they are likely to need to provide dedicated endpoints that enable the job to operate on multiple users. Most of the design work involved in designing this type of solution is around APIs rather than OAuth.