Hi All,

I am wondering what the correct process is for exposing .io integration API’s on API Gateway.
After configuring Oauth 2.0 on API gateway and adding the API, what is the next step to be able to access an API on .io integration as my understanding is basic auth is still required on .io. Without providing this you will get a native provider 401 error returned by APIGW.
What is the correct process for Auth here?
Thank you.

Yes you need to present basic auth credentials to webmethods.io Integration.
Here’s what you need to do:

1. Configure a technical wM.io Integration user in SAG Cloud, which you’ll use to access your API. Only grant Integration access to this user.
2. In your API proxy in the gateway, add a “Outbound Auth - Transport” policy with the authentication scheme “Basic”. In this policy you can configure your technical wM.io Integration user.

This way, your API proxy will authorize callers using Oauth2, and will then route the API call to the wM.io Integration “backend” API with the basic auth credentials.

Note that the credentials configured in the “Outbound Auth - Transport” policy can be placed in an alias. This allows you to eternalize these credentials.

Thank you Stephane. I have a question around creating the SAG Cloud user though.
Is this to be an internal user that is used for calling all API’s we expose via APIGW or should this user be created for each integration?
Also, would this implementation effect the logging on .io? (I don’t think so, as we would filter on the integration)

Currently, wM.io Integration allows you to manage authorizations on projets using roles. If within a given project you have several APIs, you cannot restrict access to one of these APIs and not the others.
So it’s either a tech user that’s allowed to call all wM.io APIs, or APIs that are part of one or several projects.
Whether you should use the same tech user for all APIs, or several users authorized on specific projects depends on your non functional requirements.
The earlier is easier to implement and manage, the latter reduces the impacts of credentials leaks but is more complex to deal with.

Regarding logging, this would have no impact, or little impact, especially if you filter on the project or integration name.

Hello everyone,

We’ve recently exposed our .io APIs on an API Gateway using OAuth 2.0 for enhanced security. Integrating with an Identity Provider (IdP) has been beneficial, but we’ve faced challenges with token validation and lifecycle management.

For those with similar setups:

1. What are your strategies for efficient token management and validation?
2. How do you handle token revocation and expiration?
3. Any recommended tools or libraries for OAuth 2.0 integration?

Looking forward to your insights!

Best,
Kodexolabs

@kodexlabs, maybe you could start a separate thread to deal with these aspects?

Regarding your implementation, please let us know which grant types you’re using, and if you’re also using OpenID Connect tokens.