Authenticating using OIDC

[pim.g...@gmail.com]

I have some unexpected behavior authenticating using the OIDC protocol, working with the 3Scale SaaS and APICast 3.1 release (via docker). 

When looking at the following documentation/examples/etc.

https://github.com/3scale/apicast/blob/3.1-stable/doc/oauth-guide.md 

https://access.redhat.com/documentation/en-us/red_hat_3scale/2.saas/html/api_authentication/oauth2#server_side_web_applications_authorization_code_grant_flow

https://issues.jboss.org/secure/attachment/12424346/OIDC%20flow%20with%203pty%20Idp%20and%20RH-SSO%20as%20broker%20%20%281%29.png 

It seems that the way for obtaining an access_code and later an access_token should flow through the APICast gateway. Using /authorize and /oauth/token endpoints. This is also what Im getting from https://github.com/3scale/apicast/blob/3.1-stable/apicast/src/oauth/apicast_oauth.lua (although my Lua knowledge are limited)

However, when looking at this blogpost: https://developers.redhat.com/blog/2017/11/21/setup-3scale-openid-connect-oidc-integration-rh-sso/ 

They obtain the access_code and access_token directly from Red Hat SSO/Keycloack

I was under the impression that OIDC leverages the Oauth grant flows (I configured Red Hat SSO for using the 'Authorization Code' grant flow), and I was suspecting similar behavior using Oauth2 and OIDC.

However obtaining the access_code and access_token via APIcast doesn't seem to work in my case. The /authorize and /oauth/token does not seem to be registered. Resulting in either a 404 or 403 (authentication parameters missing)

Obtaining the access_code and access_token directly from the Red Hat SSO server works like a charm, also in combination with 3Scale/APiCast.

So should for OIDC the tokens be obtained via APIcast (and am I missing something in my setup) or do the tokens need to be obtained directly from Red Hat SSO and is there a difference between Oauth2 and OIDC?

Anyone else noticed this behavior, or am I simply missing something in my setup?

Kind regards,

Pim 

[Kevin Price]

Hi Pim,

The OAuth logic you are looking at in the upstream is for the plain OAuth flow in APIcast. This means that in this integration the gateway acts as the token master and requires an Authorisation Server for user authentication only. You are right in this case that the gateway is called directly to initiate the OAuth flow. However, the blog post is a guide on how to integrate APIcast with RH SSO (aka Keycloak) through the OIDC protocol. The OIDC protocol also supports the 4 OAuth 2.0 flows which in turn are supported in RH SSO 7.1 . In this integration, however, the IdP is called directly by the client to retrieve an access token or JWT. Only once a JWT has been successfully obtained by the client does APIcast then enter the flow. The prerequisite here is an existing RH SSO server, the integration point for this server is configured in the integration page on your 3scale admin portal. You can follow the steps in [1] for more details. This would require a subscription to use the RH SSO product but you are free to use the open source version, "Keycloak", to test the integration and behaviour (We only test against the productised version of the upstream project).

[1] https://access.redhat.com/documentation/en-us/red_hat_3scale/2.saas/html/api_authentication/rhsso

Cheers,

Kev

[pim.g...@gmail.com]

Thanks Kevin, this explains the behavior. 

We are using SSO, and have it working like you described. 

Op maandag 15 januari 2018 17:10:19 UTC+1 schreef Kevin Price: