How to implement personal access tokens?

devin15
Participant I

Many public APIs offer developers the ability to create a "personal access token" as an alternative to OAuth 2.0 for simple scripts. Are there any examples of implementing such a system with Apigee? If not, can you provide an outline of what it would take to implement it?

I was thinking I could use the Edge API to create a developer and app. Then use a custom flow to create a long lived OAuth 2.0 access token for the newly created app.

1 8 1,428
8 REPLIES 8

sidd-harth
Participant V

I am not sure about personal access tokens and never came across such a topic in Apigee.

BTW as you mentioned, you can always create a developer and app in the UI and generate a long-lived token for personal use.

I was thinking I could use the Edge API to create a developer and app. Then use a custom flow to create a long lived OAuth 2.0 access token for the newly created app.

This will certainly work. The design model for OAuth tokens in Apigee Edge is for the tokens themselves to be short-lived and constantly refreshing.

If you have long-lived tokens it means the token store must accumulate these things and hold onto them for longer. This isn't a problem, unless you have a very large number of long-lived tokens. Meaning 10's or 100's of millions of long-lived tokens. That would start to be a problem, perhaps, and we'd want to talk with you about your use case.

Aside from that, I don't know what a "personal access token" really is. You could just use the API Key - this is intended to be longer-lived than a token, and you can also set expiry on keys. Not sure why you'd need the OAuth token concept if you just want to issue it once and forget it. That sounds like an API key to me.

But either way will work.

Our current implementation supports two types of authorization:

  • API key with HTTP Basic Authentication (our proxy just forwards the auth header)
  • OAuth 2.0

OAuth 2.0 provides authorization for both application and user in our system (our user ID is kept with the access token).

We'd like to remove support for HTTP Basic Authentication while still providing the simplicity of embedding credentials into simple scripts. This is similar to how other public APIs offer personal access tokens: GitHub, Azure.

The challenge with API keys is that they only represent the application. Perhaps a solution is to associate our system user ID with the application (via attributes) or app credentials.

Hi @devin15,

We have the exact requirement. Could you please let us know which approach did you finally implement?

I'm not the person to whom you directed this question.

But I still don't understand  what a "personal access token" really is.  Why not just use an API Key?  

 

For an API call, we need to represent two entities: the developer's app and the user in our system.

An Apigee API key only identifies the application. I couldn't figure out a way to also associate an API key with a user ID in our system. When the request makes it to my system, I need to know which user account the API call is for.

API keys are acceptable for applications where there isn't a user account. For example, an API that provides weather data.

@dchiesa1, I believe @devin15 has answered your question about need for "personal access token" over API key. In our case we also need to associate scopes, something similar to github personal access token, user can create multiple token with different scopes and manage the tokens independently.

We are exploring the long-lived access token option as you suggested in your earlier post, which will enable us to reuse the authorization/consent flow while generating the token.

We built a PAT internally. We have a page inside our application that lets our users create PATs.

Developers make API calls using an API key and a PAT. Apigee uses the API key to verify the application is allowed to make API calls. The PAT is passed through to our systems, where we validate the user.