Background

My application is getting data from many different sources (APIs) and aggregating across them. So the user logs via OAuth2 into the source once and afterward I continuously make calls to the source.

I am using thephpleague/oauth2-client to connect to different services, I also use provider packages build on top to connect to different websites. I have absolutely no issue there.

Once I authenticate I get an League\OAuth2\Client\Token\AccessToken instance.

Current situation

Right now for storage, I do a json_encode on the AccessToken instance and store the resulting unstructured string. To load it, I json_decode and create a new instance via the constructor. Not really interesting.

The question

If I wanted to store the access token(the OAuth response in general) a structured way, what data would I need? What do I need to persist for server-to-server communication? The specific items and their types? I am trying to figure out the data model for storing many different providers.

#Sources The sources for the answer are 2 fold:

1. The RFC: https://www.rfc-editor.org/rfc/rfc6749#section-5.1 - Given the RFC the fields are:

• access_token - a REQUIRED value of pseudotype string
• token_type - a REQUIRED value of pseudotype string
• expires_in - a recommended value of pseudotype int
• refresh_token - an optional value of pseudotype string
• scope - an optional value of pseudotype string in case of different granted scope from the scope asked in the request

The RFC stipulates that The client MUST ignore unrecognized value names in the response., however in the example, they provide in this section, they include a previously undefined value name.

2. The library mentioned: https://github.com/thephpleague/oauth2-client/blob/master/src/Token/AccessToken.php#L59 - Given the constructor:

• access_token - a REQUIRED value of pseudotype string
• resource_owner_id - a optional value of pseudotype string
• refresh_token - an optional value of pseudotype string
• expires_in - a optional value of pseudotype int with fallback to expires as a value of pseudotype int

Whatever else is passed into the constructor is treated as extra data.

#Implications

• access_token and refresh_token should be stored, both as a string with the caveat that refresh_token can be null
• token_type is implied in the library used and is not necessary in this case, but might be for some other people.
• expires_in should be stored as some representation of a point in time.
• resource_owner_id is a custom value name that your library can work with. Store it as a string if you want to use it.
• scope could be useful to store if your application tests for scope authorization before an API request. Store it as string.
• anything else is a custom value and should be treated as such. There is really low chance of overlap in value names between different providers. can be stored as an array of string.