request help: How to support third-party oauth2 authentication？

[Caelebs]

Issue description

How to support third-party oauth2 authentication？ E.g github oauth

Environment

• apisix version (cmd: apisix version):1.5
• OS:K8S

[Yiyiyimu]

Have you take reference in plugin authz-keycloak? It seems could work with third-party oauth authentication.

[sshniro]

The openid-connect plugin providest token introspection, therefore if you have a valid token, it will authenticate the token with the third-party oauth2 server.

@Caelebs Can I know what do are you referring by the term authentication? If a user accesses a route without a token, then redirect the user to third party auth and obtain the token?

[Caelebs]

I have a user authentication service, e.g. http://10.10.10.10:8080/auth/token, the requested parameters require username and password, the return value contains the token, I tried authz-keycloak and openid-connect, But none of them seem to meet the requirements?

as you said -- If a user accesses a route without a token, then redirect the user to third party auth and obtain the token? I don’t know how to jump to the authentication server to get the token when the user does not have the token

@sshniro @Yiyiyimu

[jenskeiner]

@Caelebs Sorry I'm late to this conversation.

The openid-connect plugin enforces that a valid bearer token is present in incoming requests. It supports different modes of operation. When setting bearer_only to true, it will basically act as a resource server (RS) and only validate incoming tokens. If no token is presented or if it is invalid, the request is rejected.

Additionally, if bearer_only is false, the plugin will answer with a redirect to the ID providers authorization endpoint to initiate the OIDC authorization code flow. In this case, the plugin acts as a Relying Party (RP). This only really works nicely if you're sending the initial request from a web browser that will follow the request and present you with the ID providers authentication options, typically some sort of login form. More redirects follow until the plugin can obtain a token on your behalf and store it for you, typically in a session cookie. Subsequent requests then send the cookie and the plugin can extract the token from there and validate it.

The RP flow is not really suitable for service-to-service communication where redirects may often be undesired.

The auth-keycloak plugin will be of no use here since it's only concerned with authorization of already authenticated requests. It already expects a (valid) token in a request header (so you should use the openid-connect plugin in front of it to enforce the token gets put into at the Authorization header when it's coming in through a cookie). It then leverages Keycloaks half-standardized Authorization Services API endpoints to check if the requestor has the needed permissions.

Let me know if I can help you with the setup because I've got both plugins running together with Keycloak just fine now (after some recent code changes). You should be able to get the RP flow working if your ID provider/authentication service is OIDC compliant.

[spacewander]

Consider solved

[sshniro]

Better the above description is documented in OpenID connect docs as well, as I see similar questions popping up in similar contexts, confusing authorization with authentication.

[spacewander]

@sshniro PR is welcome!

[exotfboy]

@Caelebs Hello, we meet the same requirement of integrating github/google account login in our application, how do you implement that?