Best practice for REST API token for background automation.

[jack_carico]

Are there any best practice recommendations for generating tokens for use by background IT automation processes? Currently I am using an access token generated under by admin user on our test site for interactions with the REST API. This background process will not be able to use an OAUTH workflow as there will not be a user agent available. It would also be nice to have an access token with less surface area than full admin access.

I did see that developer keys can be generated with explicit scope on the REST API but I could not find a way to use them without an OAUTH user-agent based token workflow. 

[bbennett2]

I feel like I need to preface with, "I'm not a security expert." This is just what I tend to do.

For specific processes, I create specific keys and set expiration dates. I don't have many background, long-running tasks, so I try not to have open keys floating around under the admin account. Expirations help me stay on top of that. If I really need to do something, it's easy to kick up another key for that particular job.

You can scope out API keys without needing OAuth. In the Admin page, go to Developer Keys and create a new API key. All you really need is a title and owner email. Then, hit the Enforce Scopes toggle and you can select which endpoints you want to open up to the application.

When you save, it adds your application to the keys list. To get the API key as a string, click on Show Key. That key can be used in background applications to make authenticated API calls without kicking off the OAuth flow.

The Canvas docs have this process written up with screenshots.

[jack_carico]

Brian,

How are you generating a long lived access token from the developer key? As far as I can tell the developer keys are explicitly intended to be used in an OAUTH workflow and are not tokens that can be used in the HTTP authorization header.

[bbennett2]

Jack,

That's my fault. I misunderstood how those tokens were used when compared with a normal, user-based API token. Sorry

User tokens are scoped to their particular permissions (ie, a teacher can't access a course they're not a teacher in, etc). Could you create a custom worker user to use for API calls?

[jack_carico]

No problem,

The custom user is exactly the direction I was going to explore next. I think I may be able to create an Account Role which is close enough and use a token created under an special purpose user assigned to that role. The developer key scopes are a far better match but sadly don't seem to apply here. Azure AD has exactly this feature for API keys but I understand that this is probably a far more niche scenario in Canvas.