Regardless of which grant type you used, or whether you used a client secret, you now have an OAuth 2.0 Bearer Token you can use with the API.
There are two ways API servers may accept Bearer tokens. One is in the HTTP
Authorization header, the other is in a post body parameter. It’s up to the service which it supports, so you will need to check the documentation to know for sure.
When passing in the access token in an HTTP header, you should make a request like the following:
POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia" Host: api.authorization-server.com description=Hello+World
If the service accepts access tokens in the post body, then you can make a request like the following:
POST /resource/1/ HTTP/1.1 Host: api.authorization-server.com access_token=RsT5OjbzRn430zqMLgV3Ia &description=Hello+World
Keep in mind that since the OAuth 2.0 spec doesn’t actually require one option or the other, you will have to read the API documentation for the specific service you are interacting with to know whether they support post body parameters or HTTP headers.
The access token is not intended to be parsed or understood by your application. The only thing youd application should do with it is use it to make API requests. Some services will use structured tokens like JWTs as their access tokens, described in Self-Encoded Access Tokens but the client does not need to worry about decoding the token in this case.
In fact, attempting to decode the access token is dangerous, as the server makes no guarantees that access tokens will always continue to be in the same format. It’s entirely possible that the next time you get an access token from the service, it will be in a different format. The thing to keep in mind is that access tokens are opaque to the client, and should only be used to make API requests and not interpreted themselves.
If you are trying to find out whether your access token has expired, you can either store the expiration lifetime that was returned when you first got the access token, or just try to make the request anyway, and get a new access token if the current one has expired. See below for more details on getting new access tokens using refresh tokens.
If you’re trying to find out more information about the user who signed in, you should read the API docs of the particular service to find out their recommendation. For example, Google’s API uses OpenID Connect to provide a userinfo endpoint that can return info about the user given an access token. We walk through a complete example of that workflow in Signing in with Google.