Service provider trying to connect existing OIDC app to Duo

There is a Duo Access Gateway user who would like to enable SSO to my company’s web app. Normally we would just do the OIDC details exchange and be done. Sometimes (like now) I need to dig into the documentation because there is some kind of oddity.

Created a free trial account to poke through the UI. It looks like they can go to Applications->Protect an application->Search Auth API. From there it looks like a standard OIDC flow.

Reading through the Auth API documentation there seems to be some spec changes? Is this a superset and standard OIDC will still work?

Could someone check my understanding of the different terminology Duo uses compared to OIDC? Integration Key = ClientID
Secret Key = Client Secret
API hostname = Authority
??? = MetadataAddress

What would the MetadataAddress be? Guessing it is Authority plus something standardized?

Also, I did note that the Auth API documentation said to make sure “response_type” is set to “code”.

Thank you for any help you can provide!

If I understand your question, you have a user of your web application that also has Duo Access Gateway installed, and they want to federate Duo Access Gateway with your application for SSO. Your web application already supports SSO.

First, don’t use the Auth API for this! This is not the correct integration for Duo SSO.

If your web application supports SAML 2.0, the Duo Access Gateway customer would create a generic SAML application where they could specify the SSO information you provide for your application: Entity ID, ACS, etc.

If your web application does not support SAML 2.0 (like if it is only OIDC), well, Duo Access Gateway ONLY supports SAML 2.0 service providers.

The OIDC Auth API is not a full OIDC implementation. It’s derived from OIDC standards and only delivers authorization, not authentication. It is used for integrating Duo 2FA directly into an application. The application continues to handle primary authentication.

ETA: Our Web SDK is built on the OIDC-derived API, if you want to see how it’s implemented.

That was very helpful, thank you. Will try the generic SAML application.

Our web app started with SSO via OIDC and recently we added SAML 2. Have been super spoiled by the simplicity of OAuth2/OIDC.

Because our SAML 2 is so new I don’t immediately know if an error is an edge case failure in our implementation or if their side is misconfigured.

If you ever implement a “generic OIDC application” then count me as a fan! The Auth API does look pretty close.