Emphasise that OIDC is only for interactive users #3875
Conversation
OpenID Connect is a protocol for authenticating interactive users. However, because identity platforms that support OIDC often support other protocols that can be used for non-interactive users, it is common for readers to end up on the OIDC page looking for ways to authenticate non-interactive users. The docs attempt to correct this misconception by refering to a "web application" but that was easy to miss. This change makes it more explicit that OIDC is not a viable option for service authentication and recommends JWT instead.
🔍 Preview links for changed docs |
yetanothertw
left a comment
yetanothertw
left a comment
There was a problem hiding this comment.
Thank you for your contribution! 🪴
I've approved the PR and left 2 minor suggestions for style and clarity for your consideration.
deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md
Outdated
Show resolved
Hide resolved
deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Vlada Chirmicci <[email protected]>
|
|
||
| ::::{note} | ||
| The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted. | ||
| {{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you wish to authenticate a service, the [JWT](jwt.md) realm may be a suitable alternative. |
There was a problem hiding this comment.
Suggestion: it might help to clarify that the JWT realm does (or at least, can) leverage the customer's existing OpenID Provider as the source of signed JWTs and provides the PKI for verifying said JWTs?
My sense from the SDHs we have had is that customers tend to think "JWT realm" is something alien that will take them away from the comfort and familiarity of their Entra, Okta, etc setups. They're not seeing their infra fitting into the picture.
There was a problem hiding this comment.
Probably. I struggled to come up with the right words that were succinct enough but didn't over promise.
Whether JWT actually
a. works with their existing infrastructure
b. solves their problem
is hard to predict. It probably does, but that requires more words than we want to put here.
Do you have suggested words?
In the end all it really needs to prompt is "Really, please follow that link and go read that page and hopefully it will all make sense to you" but I don't think we want to write that.
There was a problem hiding this comment.
"If you wish to authenticate a service, the JWT realm (which can integrate with tokens issued by an Open ID Provider) may be a suitable alternative. "
is what I can come up with. If we don't like parentheses, we can probably re-arrange it a bit!
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
couple of small grammar suggestions for the changed content
| The OpenID Connect realm is designed to allow users to authenticate to {{kib}}. As a result, most sections of this guide assume {{kib}} is used. This section describes how a custom web application could use the relevant OpenID Connect REST APIs to authenticate the users to {{es}} with OpenID Connect. | ||
|
|
||
| ::::{note} | ||
| The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted. |
There was a problem hiding this comment.
| The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted. | |
| The OpenID Connect protocol enables authentication for interactive users through a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted. |
|
|
||
| ::::{note} | ||
| The OpenID Connect protocol enables authentication for interactive users via a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted. | ||
| {{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you wish to authenticate a service, the [JWT](jwt.md) realm may be a suitable alternative. |
There was a problem hiding this comment.
| {{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you wish to authenticate a service, the [JWT](jwt.md) realm may be a suitable alternative. | |
| {{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you want to authenticate a service, the [JWT](jwt.md) realm might be a suitable alternative. |
4 participants
OpenID Connect is a protocol for authenticating interactive users. However, because identity platforms that support OIDC often support other protocols that can be used for non-interactive users, it is common for readers to end up on the OIDC page looking for ways to authenticate non-interactive users.
The docs attempt to correct this misconception by refering to a "web application" but that was easy to miss. This change makes it more explicit that OIDC is not a viable option for service authentication and recommends JWT instead.