![[The AI Show Episode 144]: ChatGPT’s New Memory, Shopify CEO’s Leaked “AI First” Memo, Google Cloud Next Releases, o3 and o4-mini Coming Soon & Llama 4’s Rocky Launch](https://www.marketingaiinstitute.com/hubfs/ep%20144%20cover.png)
.jpg?#)
.png?#)
.jpg?width=1920&height=1920&fit=bounds&quality=70&format=jpg&auto=webp#)
_Aleksey_Funtap_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale#)
![[Fixed] Gemini app is failing to generate Audio Overviews](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/03/Gemini-Audio-Overview-cover.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
![Apple Seeds tvOS 18.5 Beta 2 to Developers [Download]](https://www.iclarified.com/images/news/97011/97011/97011-640.jpg)
![Apple Releases macOS Sequoia 15.5 Beta 2 to Developers [Download]](https://www.iclarified.com/images/news/97014/97014/97014-640.jpg)
Getting Authentication Right is Critical to Running MCP Servers
Any time you’re connecting APIs, you have to consider security implications. The same is true for Model Context Protocol Servers. In our experience, it’s important to have a strong separation of authentication (verifying who you are) and authorization (deciding what you can do). We built ToolHive to make it easier and more secure to run MCP Servers. In this post, we’ll explore why ToolHive leverages OpenID Connect (OIDC) for authentication, how it distinguishes authn vs authz, and real-world scenarios it enables – from Google sign-ins to Kubernetes service tokens. (A follow-up post will dive into ToolHive’s built-in authorization framework in detail.) Authentication vs Authorization in ToolHive It’s crucial to understand the difference between authentication (authn) and authorization (authz). Authentication is about identity – proving who is making a request (e.g. via a login or token). Authorization is about permissions – determining if that identity is allowed to perform a given action. ToolHive treats these as separate concerns. In practice, this means ToolHive first ensures it knows who the caller is (authenticating via OIDC), and only then applies rules about what that caller can do (ToolHive’s own permission model). By explicitly separating authn and authz, ToolHive can rely on well-proven identity systems for authentication and avoid conflating identity with access control. This leads to a cleaner, more secure design. Why OpenID Connect for Authentication? OpenID Connect (OIDC) is a widely adopted protocol for user authentication built on OAuth 2.0. It provides a standard way to get an identity token (usually a JWT) that confirms a user’s identity, issued by a trusted Identity Provider (IdP). In other words, OIDC lets ToolHive outsource the heavy lifting of verifying identities to providers like Google, GitHub, or corporate SSO systems, and then consume a verifiable assertion of the user’s identity (How OpenID Connect Works - OpenID Foundation). This has several advantages: Standard and Interoperable – OIDC is an interoperable auth protocol based on OAuth2, simplifying identity verification. Because of this, ToolHive can integrate with any OIDC-compliant identity provider without custom code. The protocol even supports features like discovery and JWT signature verification out-of-the-box, making integration easier and less error-prone. Proven and Secure – By using OIDC, ToolHive leverages the security of battle-tested identity systems. OIDC providers handle the user login UI, multi-factor auth, password storage, etc., so ToolHive itself never sees raw passwords or credentials. ToolHive simply trusts the ID token from the provider if it’s correctly signed and not expired. Decoupled Identity Management – Adopting OIDC means ToolHive doesn’t have to be its own identity service. Instead of reinventing user management, it “piggybacks” on existing identity solutions. For organizations, this is huge: you can plug ToolHive into your existing SSO/IdP (Google, Microsoft Entra ID, Okta, etc.) and instantly use those identities. Flexible for Humans and Services – OIDC isn’t just for interactive user login. It also works great for service-to-service auth via JWTs. ToolHive’s use of OIDC means it can authenticate both end-users and other services in a unified way (more on this below). The common factor is that identity is conveyed through a trusted OIDC token, whether it came from an OAuth web flow or from a service account in Kubernetes. OIDC Use Cases in ToolHive How does this OIDC-based authentication play out in practice? Here are two common scenarios where ToolHive’s approach shines:
Any time you’re connecting APIs, you have to consider security implications. The same is true for Model Context Protocol Servers. In our experience, it’s important to have a strong separation of authentication (verifying who you are) and authorization (deciding what you can do).
We built ToolHive to make it easier and more secure to run MCP Servers. In this post, we’ll explore why ToolHive leverages OpenID Connect (OIDC) for authentication, how it distinguishes authn vs authz, and real-world scenarios it enables – from Google sign-ins to Kubernetes service tokens. (A follow-up post will dive into ToolHive’s built-in authorization framework in detail.)
Authentication vs Authorization in ToolHive
It’s crucial to understand the difference between authentication (authn) and authorization (authz). Authentication is about identity – proving who is making a request (e.g. via a login or token). Authorization is about permissions – determining if that identity is allowed to perform a given action. ToolHive treats these as separate concerns.
In practice, this means ToolHive first ensures it knows who the caller is (authenticating via OIDC), and only then applies rules about what that caller can do (ToolHive’s own permission model). By explicitly separating authn and authz, ToolHive can rely on well-proven identity systems for authentication and avoid conflating identity with access control. This leads to a cleaner, more secure design.
Why OpenID Connect for Authentication?
OpenID Connect (OIDC) is a widely adopted protocol for user authentication built on OAuth 2.0. It provides a standard way to get an identity token (usually a JWT) that confirms a user’s identity, issued by a trusted Identity Provider (IdP). In other words, OIDC lets ToolHive outsource the heavy lifting of verifying identities to providers like Google, GitHub, or corporate SSO systems, and then consume a verifiable assertion of the user’s identity (How OpenID Connect Works - OpenID Foundation). This has several advantages:
Standard and Interoperable – OIDC is an interoperable auth protocol based on OAuth2, simplifying identity verification. Because of this, ToolHive can integrate with any OIDC-compliant identity provider without custom code. The protocol even supports features like discovery and JWT signature verification out-of-the-box, making integration easier and less error-prone.
Proven and Secure – By using OIDC, ToolHive leverages the security of battle-tested identity systems. OIDC providers handle the user login UI, multi-factor auth, password storage, etc., so ToolHive itself never sees raw passwords or credentials. ToolHive simply trusts the ID token from the provider if it’s correctly signed and not expired.
Decoupled Identity Management – Adopting OIDC means ToolHive doesn’t have to be its own identity service. Instead of reinventing user management, it “piggybacks” on existing identity solutions. For organizations, this is huge: you can plug ToolHive into your existing SSO/IdP (Google, Microsoft Entra ID, Okta, etc.) and instantly use those identities.
Flexible for Humans and Services – OIDC isn’t just for interactive user login. It also works great for service-to-service auth via JWTs. ToolHive’s use of OIDC means it can authenticate both end-users and other services in a unified way (more on this below). The common factor is that identity is conveyed through a trusted OIDC token, whether it came from an OAuth web flow or from a service account in Kubernetes.
OIDC Use Cases in ToolHive
How does this OIDC-based authentication play out in practice? Here are two common scenarios where ToolHive’s approach shines:
