OAuth 2.0 flow in brief and Google OAuth Playground Quick Check Out
In the middle of looking at Snowflake external OAuth capability…so I need an OAuth 2.0 server. It seems Okta has limited what a free account can do to setup an OAuth/OIDC server/application. So trying to look for a good OAuth service.
1 OAuth 2.0 in brief
As we know that OAuth 2.0 provides trusted “machine (application script as client) to machine (targeting resources/services)” interaction via an access token among three participants:
1> Application client (Python code for example) who wants to consume resource
2> Targeting resources like APIs or databases (Snowflake for example) etc. and
3> OAuth services who provides access token. To be precise, OAuth services have endpoints — 2 out of them are mentioned here: authorization endpoint and token endpoint.
0> Application as client (Python script or Postman etc.) needs to be registered in OAuth server providing (depending on server implementations)
- redirect URL of the app,
- allowed resource scope (allowed REST API URLs or Snowflake role names etc.),
- allowed grant type (credential type client uses to ask grant/code/token) and
- audience(resource URL — Snowflake account URL) etc.
Client id and client secret are then assigned for this app client. This step is done by OAuth server administrator.
Note, IDP service for resource owner user identities are also maintained along with authorization service. It’s like Google user identities as resource owners of Google APIs.
In our case, we’re looking at IDP service and OAuth service outside of targeting resource Snowflake account. So Snowflake needs to be configured using SSO with the IDP first.
1> Application client asks access token from OAuth server in order to access resources
First, application client asks authorization code from OAuth server (authorization service endpoint) by providing client id, response type, redirect URL and scope.
- client_id: tells OAuth server which application client is. Multiple clients can be registered in one authorization service.
- response_type: the value should be “code” now to ask a authorization code back to client.
- redirect_url: tells OAuth server that where the code should be sent back from OAuth server and where next requests will come — redeem code for access token. So it’s an URL representing application client.
- scope: is about the resource that application client wants to access. for REST service as targeting resource it’s an API URL, for Snowflake it’s role name. This scope info will be put into authorization code and access token further next to define what resource application client can access.
When asking code, identity service(IDP) related to authorization service will need to authenticate resource owner. Then the resource owner needs to consent based on the requested resource scope. And all that is done, authorization server returns code to given client app redirect URI.
Second, once authorization code is received application client asks OAuth service token endpoint to redeem authorization code for access token. code first and token second are for better security(details). Access token is usually JWT format.
3> Application to access targeting resources presenting this access token(usually in rest request header as bearer token).
Note, resource doesn’t know the user identity of application. Resource opens given scope access defined in access token based on specific client ID. We know when acquiring access token/code resource owner/user has consented for the resource access scope to this client ID. And the same resource owner/user can consent different scopes to different client IDs.
2 A quick look at Google OAuth 2.0 Playground to see if we can leverage it as external OAuth 2.0 service for Snowflake access.
OAuth 2.0 Playground acts as application client role. Playground asks for access token from Google OAuth servers and then use it to access resources of Google APIs.
2.1 Ask for authorization code
Playground lists all the scopes for us to choose — they are Google API endpoints. So those scopes won’t work for Snowflake as resource. We can not use Google OAuth Playground service for Snowflake. But let’s quickly complete this playground anyway.
Google playground acts as client app asking access to given scope/Google Calendar API. Authorization service brings us to authentication and consent page after clicking “Authorize APIs” button.
After consent page is completed, authorization service sends us back to “redirect uri” Google Playground again but with our authorization code.
2.2 Redeem authorization code for access token
We can then use playground function to redeem code for access token.
2.3 Call Google Calendar API presenting access token
Note, calendarId parameter in API call is our Google email address. So list events call can be like this:
https://www.googleapis.com/calendar/v3/calendars/fengliplatform@gmail.com/events
“Send the request” and see how it returns event list successfully.
So Google OAuth Playground service (Same behaviors for an OAuth ID credential in a GCP project) is to demonstrate how to protect Google resources like API endpoints. It can not be used as separate OAuth service to protect Snowflake resources while paid Okta service is supposed to be able to do this.
Happy Reading!
