apigee as oauth 2.0 authorization server for external .NET web API...

I want to use apigee as token provider and authorization server for .NET web APIs. How can i implement this?

0 5 969
5 REPLIES 5

schhatwal
Participant I

@Surabhi.gupta

Apigee can be used as Token Manager and Authorization server .Here are few quick steps which can be taken to implement this style.Use Oauth 2.0 policy for token management

1) /generate-token : This configuration mode requires api-key , grant type , user/app credentials (authorization), scopes . and any custom attributes to embed in the token as input . Oauth 2.0 policy will be configured in {generate mode} . You should perform User/app Credential validation before generating this token.

To use Apigee as the Authorization Server you may need to use BaaS for user management . Please refer to the BaaS docs for further details or follow this link , see this response from @Dino for sample code.

The other options for Authorization are using an IDP outside Apigee.

2) /refresh-token : This step does not require authorization and the Ouath 2.0 policy needs to be configured in "refresh" mode . The inputs required are grant type , refresh token from the generate step .

3) /revoke-token : this step just needs to pass the token to be revoked and Oauth2.0 policy needs to be configured in InvalidateToken mode

Please feel free to reach out if you need further information !

Cheers !

Saurabh

Hi @schhatwal,

Thanks for providing the solution. i have couple of questions:

about generating token, you suggested we use userapp/production in apigee. so if I create a product for no-proxied api, what would be the resource; complete URL of the non-proxied API?

How do we do credential validation to make sure correct resource is being accessed before generating the token?

schhatwal
Participant I

@Surabhi.gupta

Trying to elaborate on the scenario and have broken up the questions in parts to allow enhanced understanding :-

1. What is the Resource / Resource Server ?

In this case Apigee Edge is the Resource Server in addition to being the Authorization Server

2. What is the complete resource URL ?

The URL of the API Proxy used for validating the Oauth 2.0 Token. This is separate from the Oauth Token Manager I have elaborated on the initial post as this is the Consumer API after the Token generation / refresh has completed in a separately implemented Oauth Manager.A typical implementation of Consumer/Resource API is to place Oauth 2.0 policy in Validation mode in the pre-flow of the API you want to protect .

3. Why No-Proxied API ?

There is no reason for directly exposing the target if you are using Apigee Edge. The implementation should never use a no-proxied API and should have a minimum of reverse proxy implementation with Oauth Policy in validation mode in the pre-flow.

4. How to perform Credential Validation ?

The credential validation part can be handled using an IDP of your choice . It could be an LDAP validation , External IDP like facebook, Apigee BaaS user management can also be used for credential validation.

5. How to make sure correct resource is being accessed before generating the token ?

Token Generation and Resource access are mutually exclusive but Token Generation should happen before resource access and not the other way around .

The token can be minted by presenting correct credentials , scopes and any custom attributes required.

The resource {API proxy} should implement the access by placing Oauth Policy in front of the API pre-flow to provide validation

I hope this helps .Please let me know if you need further details

Cheers!

Saurabh

@schhatwal

Thanks Saurabh for your prompt response. this is all working in our environment when API is proxied through apigee.

The solution I am looking for is oauth implementation using apigee for non-proxied APIs so we can replace current in-house oauth implementation.

@Surabhi.gupta

Oauth 2.0 is a Product feature which cannot be externalized. This use case will require placing a custom call from your API to the Apigee Server to validate the token which is not a recommended solution.

The pattern your are planning to use will also distance you from taking advantage of developer portal and Apigee framework of Apps built using Products created using a combination of proxies.This will also prevent you from getting Apigee Analytics.

So just to summarize our take on the approach :-

Doable ? Yes

Reccomended ? No

PS : I am curious to know why you don't want to proxy your API's with Apigee in case you dont accept the recommended approach