Hi ,
I need to connect Snowflake server using the Azure OAuth -Authorization code grant type from apigee. I have used the service call out policy to generate the access token from Azure server to connect snowflake. I have used the existing refresh token to generate the access token. But I want generate the access token without refresh token using the service account credentials.
Initially I am using the POSTMAN to generate the access and refresh token by passing service account but same kind of implementation need to do in apigee.
I need to implement target system authorization code grant type in apigee.
POSTMAN Screenshot:
Could you please help with this, @dchiesa1
Solved! Go to Solution.
I understand what you're asking, and thanks for the clear question.
You are using an Apigee proxy to connect to Snowflake. You have a refresh token from your Azure AD tenant (side note - I understand Microsoft are renaming Azure AD to Entra ID), and are able to use that refresh token to get an access token, which then allows the Apigee proxy to connect to Snowflake. You want to get an access token without the refresh token.
So actually, the fact that Snowflake is the target here is sort of irrelevant to the question. The real question is, how to configure Apigee to get a token from Azure AD, via authorization code grant.
Authcode grant is also known as the "3-legged" grant type, because there are three actors or systems involved in the interaction. The client app, the resource server (in this case Snowflake) and the authorization server (in this case Azure AD). The point of the 3-legged flow is to require a user to interactively authenticate to the authorization server, without sharing a password or other credentials with the client app...or with the resource server. So to make that happen, the user must use a browser to connect to the authorization server to login, and then "consent" to allowing the client app to send requests on his/her behalf to the resource server.
This means Apigee by itself cannot unilaterally obtain a token via authorization code grant. Apigee cannot interactively login, on behalf of a user. The user needs to do that. You can allow Apigee to broker this exchange. In this we would say Apigee can act as an OpenID Connect facade . I recorded a screencast on this topic not long ago. There are good reasons for wanting to do this. But the key point is, the user interaction still needs to happen, if you want to use authorization code flow. That part cannot be "automated away" without compromising the integrity of the authentication model.
An alternative is to NOT use a 3-legged flow to get a token, but to use a 2-legged flow - basically a client credentials flow or equivalent - between Apigee and Azure AD to obtain a token that is good for your upstream (in this case Snowflake). For this option, you would need to set up a "service account" client in Azure AD, and authorize that client to access Snowflake. I'm not an expert in that, but I'm certain it is possible and straightforward. In that case Apigee would be "acting as itself" when connecting to the upstream (Snowflake), and would not be acting on behalf of the user.
Obviously that has implications for the security of the system, so do take care in selecting the option - 2-legged or 3-legged - that makes the most sense for you.
Good luck!
I understand what you're asking, and thanks for the clear question.
You are using an Apigee proxy to connect to Snowflake. You have a refresh token from your Azure AD tenant (side note - I understand Microsoft are renaming Azure AD to Entra ID), and are able to use that refresh token to get an access token, which then allows the Apigee proxy to connect to Snowflake. You want to get an access token without the refresh token.
So actually, the fact that Snowflake is the target here is sort of irrelevant to the question. The real question is, how to configure Apigee to get a token from Azure AD, via authorization code grant.
Authcode grant is also known as the "3-legged" grant type, because there are three actors or systems involved in the interaction. The client app, the resource server (in this case Snowflake) and the authorization server (in this case Azure AD). The point of the 3-legged flow is to require a user to interactively authenticate to the authorization server, without sharing a password or other credentials with the client app...or with the resource server. So to make that happen, the user must use a browser to connect to the authorization server to login, and then "consent" to allowing the client app to send requests on his/her behalf to the resource server.
This means Apigee by itself cannot unilaterally obtain a token via authorization code grant. Apigee cannot interactively login, on behalf of a user. The user needs to do that. You can allow Apigee to broker this exchange. In this we would say Apigee can act as an OpenID Connect facade . I recorded a screencast on this topic not long ago. There are good reasons for wanting to do this. But the key point is, the user interaction still needs to happen, if you want to use authorization code flow. That part cannot be "automated away" without compromising the integrity of the authentication model.
An alternative is to NOT use a 3-legged flow to get a token, but to use a 2-legged flow - basically a client credentials flow or equivalent - between Apigee and Azure AD to obtain a token that is good for your upstream (in this case Snowflake). For this option, you would need to set up a "service account" client in Azure AD, and authorize that client to access Snowflake. I'm not an expert in that, but I'm certain it is possible and straightforward. In that case Apigee would be "acting as itself" when connecting to the upstream (Snowflake), and would not be acting on behalf of the user.
Obviously that has implications for the security of the system, so do take care in selecting the option - 2-legged or 3-legged - that makes the most sense for you.
Good luck!
Thank you @dchiesa1 for your response. Based on the Azure docs also need the User Interaction for the Authorization code grant type. I am planning to use the Auth code instead of the refresh token. Because refresh tokens have a certain period of time validity.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Hey @Mathivanan could you please provide me detailed steps on how to connect snowflake server via apigee using 2-legged flow - basically a client credentials flow. Thant will help me a lot I am also working on the same flow.
I looked in the documentation for Snowflake, and saw a statement that Snowflake supports OAuth client credentials flow, as defined in IETF RFC 6749:
But, I could not find a clear statement in the documentation of how to use it. The Snowflake documentation does describe using the authorization_code flow, which I discussed in my reply to the original poster 3 or 4 months ago. But I could not find a page in the snowflake documentation similarly describing how to use the client credentials flow.
My understanding of this page is that Snowflake offer two options for OAuth authentication - "Snowflake OAuth" and "External OAuth". If you use Snowflake OAuth, then you must use authorization_code grant type. If you want to use other grant types, including client_credentials, you may do so only with External OAuth.
This page describes how to set up Azure AD as the Idp for "External OAuth." It also describes how to test the password grant . Maybe you can use that as a starter point for the client credentials flow. This page may also help.
Sorry I cannot provide something specific, I'm not a snowflake expert.