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:
access_token
- a REQUIRED value of pseudotypestring
token_type
- a REQUIRED value of pseudotypestring
expires_in
- a recommended value of pseudotypeint
refresh_token
- an optional value of pseudotypestring
scope
- an optional value of pseudotypestring
in case of different granted scope from the scope asked in the requestThe 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 undefinedvalue name
.access_token
- a REQUIRED value of pseudotypestring
resource_owner_id
- a optional value of pseudotypestring
refresh_token
- an optional value of pseudotypestring
expires_in
- a optional value of pseudotypeint
with fallback toexpires
as a value of pseudotypeint
Whatever else is passed into the constructor is treated as extra data.
#Implications
access_token
andrefresh_token
should be stored, both as a string with the caveat thatrefresh_token
can be nulltoken_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.