From c4cc0b68e5d383dc477ebd9b529eb7e0addbdb03 Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 14:22:40 +0200 Subject: [PATCH 1/7] Add OAuth 2.0 Token Endpoint security guide --- blog/2025-11-14-oauth2-token-endpoint.md | 153 +++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 blog/2025-11-14-oauth2-token-endpoint.md diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md new file mode 100644 index 0000000..4915dec --- /dev/null +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -0,0 +1,153 @@ +--- +slug: oauth2-token-endpoint +title: "OAuth 2.0 Token Endpoint - OneGround Security Guide" +description: "Learn why customer-generated JWTs are risky and how OAuth2 Token Endpoints provide better security, control, and simplicity for API authentication." +authors: giedriusgrabauskas +tags: [security] +keywords: + - JWT security + - OAuth2 + - Token Endpoint + - API authentication + - JSON Web Tokens + - ZGW API security + - OneGround authentication + - token validation + - API security best practices + - bearer tokens + - security implementation +--- + +# OAuth2 Token Endpoint + +We already have published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md) that clearly explains the rules for creating safe and reliable JSON Web Tokens. It emphasizes the importance of proper claims like `iss` (Issuer) and `exp` (Expiration), securely managing secrets, and using tokens that do not last long. + +This is excellent advice, but it raises a key question: **Who should be in charge of following these rules?** + +A risky pattern in API design is letting customers create their own JWTs. The idea seems simple: "Here's a secret key, Mr. Customer. Just make a JWT using our guidelines, sign it with this secret, and include it in your Authorization header." + +This method goes against best practices by making customers take on the difficult task of security. This leads to an unstable and unsafe system. + +A much better model is to use a standard **OAuth2 Token Endpoint**. Instead of asking your customer to create a token, you let them request one. + +Here's why this is a better, safer, and ultimately easier method for everyone involved. + + + +## The Problems with "Bring Your Own JWT" + +When you allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not because customers intend harm, but because creating tokens is complex. + +Here's how this approach fails, based on best practices: + +* **Cannot Control Token Expiration:** +You can suggest a 1-hour expiration, but you cannot enforce it. A developer might "fix" re-authentication issues by setting `exp` to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To address this, you would need complex validation checks, which is reactive rather than proactive security. + +* **Secret Management Issues:** +You have to share a signing secret with customers, turning their secret management into your security risk. If they leak the secret by committing it to code, embedding it in apps, or logging it, attackers could forge valid tokens indefinitely, impersonating legitimate clients without detection. + +* **Lack of Control Over Implementation:** +You cannot ensure that customers use trusted libraries. They might use outdated or insecure libraries, or attempt to create their own JWTs in insecure ways. This exposes you to attacks such as the `alg: "none"` vulnerability, where vulnerable JWT libraries may accept unsigned tokens, allowing attackers to forge tokens by skipping signature validation entirely. + +* **API Complexity:** +Your API must handle validation for tokens from various customer setups, each with its unique quirks. You must validate every claim (`iss`, `aud`, `exp`) in each request to ensure the customer has implemented it correctly. + +## The Secure & Simple Alternative: The OAuth2 Token Endpoint + +The OAuth2 framework, especially the **Client Credentials Grant** flow, offers an easy and standard solution. + +Here's how it works: + +1. **Request:** The customer (client) sends a secure HTTPS POST request to your token endpoint (e.g., `/oauth/token`). +2. **Credentials:** In this request, they include their `client_id` and `client_secret` that you provided. +3. **Validate:** Your server validates these credentials against your secure credential store. +4. **Issue:** If valid, your server generates a new JWT with appropriate claims (`iss`, `aud`, `exp`, etc.). +5. **Sign:** Your server signs the JWT using asymmetric cryptography (e.g., RS256 with your private key). This is preferred over symmetric signing because your private key never leaves your server, while symmetric methods like HS256 would still require sharing a secret. +6. **Respond:** The signed JWT is returned to the customer as an access token. +7. **Use:** The customer includes this short-lived JWT in API requests. When it expires, they simply request a new one. + +## OAuth2 Token Endpoint Practical Example + +Here's what a token request looks like in practice: + +**Request:** + +```http +POST /token HTTP/1.1 +Host: api.example.com +Content-Type: application/x-www-form-urlencoded + +grant_type=client_credentials +&client_id=abc123xyz +&client_secret=very-secure-secret-here +``` + +**Response:** + +```json +{ + "access_token": "eyJhbGciOi...", + "token_type": "Bearer", + "expires_in": 3600 +} +``` + +**Using the token:** + +```http +GET /api/resources HTTP/1.1 +Host: zgw-api.example.com +Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... +``` + +The customer doesn't worry about JWT structure, signing algorithms, or claim management. They simply exchange credentials for a token and use it. + +## Why the Token Endpoint Model is Better + +This model makes sure that the responsibility for creating tokens stays with you, the API provider. You are the Issuer (`iss`), and you have full control over the process. + +* **You Maintain All Best Practices** + * **Token Lifetime:** You set how long tokens last. If you decide they expire in 15 minutes, that's what happens. The customer cannot change it. + * **Claims:** Since you create the token, you ensure all claims (`iss`, `aud`, `exp`) are accurate, included, and standardized. + * **Algorithm:** You pick the signing method, such as `RS256`. Customers only need to use the token without knowing how it is signed. + +* **Your Private Key Stays Secret** + * The customer's `client_secret` is not a signing key. It's like a password used to request a token. If it gets leaked, the risk is smaller: + * An attacker can request tokens but cannot create them. You can detect and rate-limit this activity. + * You can revoke that `client_id` or rotate credentials. + * This is much safer than a leaked signing key, which could let an attacker create fake tokens without being noticed. + +* **Easier for Your Customer** + * Customers don't need to set up JWT libraries, handle signing keys, or manage claims. Their job is simply to make one HTTP POST request. Any developer can do this in any language without specialized tools. + +* **Better Security Controls** + * **Rate Limiting:** Protect the token endpoint with rate limiting to prevent brute-force attacks on client credentials. + * **Token Revocation:** When credentials are compromised, revoke the `client_id` immediately to invalidate all future token requests. + * **Scope-Based Access:** Issue tokens with specific scopes or permissions based on the client, enabling fine-grained access control. + * **Audit Trail:** Log all token requests to detect suspicious patterns or unauthorized access attempts. + * **Short-Lived Tokens:** Enforce brief token lifetimes (15-60 minutes) to minimize the window of opportunity if a token is intercepted. + +## Conclusion + +JSON Web Tokens are excellent for securely transmitting information. However, creating them is a delicate security task that should not be left to customers. + +By using a standard OAuth2 Token Endpoint, you manage your API's security more effectively. You can immediately apply all best practices, keep your important secrets secure, and offer a simpler, stronger, and more professional experience for your developers. + +When tokens expire, customers simply request a new one, no complex refresh logic needed for the Client Credentials flow. This keeps integration straightforward while maintaining strong security. + +Stop making your customers handle security. Centralize token creation under your control. + +## References + +* [RFC 6749: The official specification for OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +* [RFC 7519: JSON Web Token (JWT) specification](https://datatracker.ietf.org/doc/html/rfc7519) +* [RFC 8252: OAuth 2.0 for Native Apps - Best Current Practice](https://datatracker.ietf.org/doc/html/rfc8252) +* [RFC 6819: OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) +* [BCP: OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) +* [OWASP: OAuth 2.0 Protocol Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) +* [OWASP: JSON Web Token Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) +* [OWASP: WSTG Testing for OAuth Weaknesses](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/) +* [auth0.com: Critical vulnerabilities in JSON Web Token libraries](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) +* [JWT.io: Introduction to JSON Web Tokens: A beginner-friendly guide to understanding JWTs](https://jwt.io/introduction) +* [oauth.com: OAuth 2.0 Simplified](https://www.oauth.com/) +* [oauth.com: Client Credentials, OAuth 2.0 Simplified](https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/) From 57b014ba73e363d27b7ac11455c9825c8f18b6bb Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 14:31:30 +0200 Subject: [PATCH 2/7] Refine language and clarity in OAuth 2.0 Token Endpoint guide --- blog/2025-11-14-oauth2-token-endpoint.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index 4915dec..151ac4d 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -22,7 +22,7 @@ keywords: We already have published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md) that clearly explains the rules for creating safe and reliable JSON Web Tokens. It emphasizes the importance of proper claims like `iss` (Issuer) and `exp` (Expiration), securely managing secrets, and using tokens that do not last long. -This is excellent advice, but it raises a key question: **Who should be in charge of following these rules?** +But it raises a key question: **Who should be in charge of following these rules?** A risky pattern in API design is letting customers create their own JWTs. The idea seems simple: "Here's a secret key, Mr. Customer. Just make a JWT using our guidelines, sign it with this secret, and include it in your Authorization header." @@ -30,15 +30,13 @@ This method goes against best practices by making customers take on the difficul A much better model is to use a standard **OAuth2 Token Endpoint**. Instead of asking your customer to create a token, you let them request one. -Here's why this is a better, safer, and ultimately easier method for everyone involved. - ## The Problems with "Bring Your Own JWT" -When you allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not because customers intend harm, but because creating tokens is complex. +When you will allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not due to any malicious intent from customers, but because generating tokens is a complex process. -Here's how this approach fails, based on best practices: +This approach fails, based on best practices: * **Cannot Control Token Expiration:** You can suggest a 1-hour expiration, but you cannot enforce it. A developer might "fix" re-authentication issues by setting `exp` to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To address this, you would need complex validation checks, which is reactive rather than proactive security. @@ -54,9 +52,9 @@ Your API must handle validation for tokens from various customer setups, each wi ## The Secure & Simple Alternative: The OAuth2 Token Endpoint -The OAuth2 framework, especially the **Client Credentials Grant** flow, offers an easy and standard solution. +The OAuth2 framework, especially with the **Client Credentials Grant** flow, can offer an easy and standard solution. -Here's how it works: +How it works: 1. **Request:** The customer (client) sends a secure HTTPS POST request to your token endpoint (e.g., `/oauth/token`). 2. **Credentials:** In this request, they include their `client_id` and `client_secret` that you provided. @@ -102,7 +100,7 @@ Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... The customer doesn't worry about JWT structure, signing algorithms, or claim management. They simply exchange credentials for a token and use it. -## Why the Token Endpoint Model is Better +## So, why the Token Endpoint Model is Better? This model makes sure that the responsibility for creating tokens stays with you, the API provider. You are the Issuer (`iss`), and you have full control over the process. @@ -135,7 +133,7 @@ By using a standard OAuth2 Token Endpoint, you manage your API's security more e When tokens expire, customers simply request a new one, no complex refresh logic needed for the Client Credentials flow. This keeps integration straightforward while maintaining strong security. -Stop making your customers handle security. Centralize token creation under your control. +So, please stop making your customers handle security. Centralize token creation will be kept under your control. ## References From 76a717f31d9070cf1869760eabf9023d41e3e2d1 Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 14:44:39 +0200 Subject: [PATCH 3/7] Refine language and clarity in OAuth 2.0 Token Endpoint documentation --- blog/2025-11-14-oauth2-token-endpoint.md | 94 +++++++++++++----------- 1 file changed, 51 insertions(+), 43 deletions(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index 151ac4d..a354341 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -20,13 +20,13 @@ keywords: # OAuth2 Token Endpoint -We already have published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md) that clearly explains the rules for creating safe and reliable JSON Web Tokens. It emphasizes the importance of proper claims like `iss` (Issuer) and `exp` (Expiration), securely managing secrets, and using tokens that do not last long. +We already have published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md) that explains the rules for creating safe and reliable JSON Web Tokens. It emphasizes using proper claims like `iss` (Issuer) and `exp` (Expiration), securely managing secrets, and keeping tokens short-lived. -But it raises a key question: **Who should be in charge of following these rules?** +But this raises a key question: **Who should be responsible for following these rules?** -A risky pattern in API design is letting customers create their own JWTs. The idea seems simple: "Here's a secret key, Mr. Customer. Just make a JWT using our guidelines, sign it with this secret, and include it in your Authorization header." +A risky pattern in API design is letting customers create their own JWTs. The idea seems simple: "Here's a secret key, Mr. Customer. Just make a JWT using our guidelines, sign it with this secret, and include it in your `Authorization` header." -This method goes against best practices by making customers take on the difficult task of security. This leads to an unstable and unsafe system. +This approach shifts the difficult task of security onto the customer, which goes against best practices and can lead to an unstable and insecure system. A much better model is to use a standard **OAuth2 Token Endpoint**. Instead of asking your customer to create a token, you let them request one. @@ -34,35 +34,35 @@ A much better model is to use a standard **OAuth2 Token Endpoint**. Instead of a ## The Problems with "Bring Your Own JWT" -When you will allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not due to any malicious intent from customers, but because generating tokens is a complex process. +When you allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not due to any malicious intent from customers, but because generating tokens is a complex process. -This approach fails, based on best practices: +This approach falls short of best practices in several ways: -* **Cannot Control Token Expiration:** -You can suggest a 1-hour expiration, but you cannot enforce it. A developer might "fix" re-authentication issues by setting `exp` to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To address this, you would need complex validation checks, which is reactive rather than proactive security. +* **You Can't Control Token Expiration:** +You can suggest a one-hour expiration, but you can't enforce it. A developer might try to "fix" re-authentication issues by setting the `exp` claim to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To fix this, you would need to add complex validation checks, which is a reactive security measure, not a proactive one. -* **Secret Management Issues:** -You have to share a signing secret with customers, turning their secret management into your security risk. If they leak the secret by committing it to code, embedding it in apps, or logging it, attackers could forge valid tokens indefinitely, impersonating legitimate clients without detection. +* **It Creates Secret Management Issues:** +You have to share a signing secret with your customers, which makes their secret management your security risk. If they leak the secret—by committing it to code, embedding it in an app, or logging it—attackers could create valid tokens forever, impersonating legitimate clients without being detected. -* **Lack of Control Over Implementation:** -You cannot ensure that customers use trusted libraries. They might use outdated or insecure libraries, or attempt to create their own JWTs in insecure ways. This exposes you to attacks such as the `alg: "none"` vulnerability, where vulnerable JWT libraries may accept unsigned tokens, allowing attackers to forge tokens by skipping signature validation entirely. +* **You Have No Control Over Implementation:** +You can't ensure that customers are using trusted libraries. They might use outdated or insecure libraries or try to create their own JWTs in a way that isn't secure. This exposes you to attacks like the `alg: "none"` vulnerability, where some JWT libraries might accept unsigned tokens. This would allow attackers to create fake tokens by skipping the signature validation. -* **API Complexity:** -Your API must handle validation for tokens from various customer setups, each with its unique quirks. You must validate every claim (`iss`, `aud`, `exp`) in each request to ensure the customer has implemented it correctly. +* **It Increases API Complexity:** +Your API has to handle validation for tokens from different customer setups, each with its own unique issues. You have to validate every claim (`iss`, `aud`, `exp`) in each request to make sure the customer has implemented it correctly. -## The Secure & Simple Alternative: The OAuth2 Token Endpoint +## The Secure and Simple Alternative: The OAuth2 Token Endpoint -The OAuth2 framework, especially with the **Client Credentials Grant** flow, can offer an easy and standard solution. +The OAuth2 framework, particularly the **Client Credentials Grant** flow, offers a simple and standardized solution. -How it works: +Here's how it works: -1. **Request:** The customer (client) sends a secure HTTPS POST request to your token endpoint (e.g., `/oauth/token`). -2. **Credentials:** In this request, they include their `client_id` and `client_secret` that you provided. +1. **Request:** The customer (client) sends a secure HTTPS `POST` request to your token endpoint (e.g., `/oauth/token`). +2. **Credentials:** In this request, they include the `client_id` and `client_secret` that you provided. 3. **Validate:** Your server validates these credentials against your secure credential store. -4. **Issue:** If valid, your server generates a new JWT with appropriate claims (`iss`, `aud`, `exp`, etc.). -5. **Sign:** Your server signs the JWT using asymmetric cryptography (e.g., RS256 with your private key). This is preferred over symmetric signing because your private key never leaves your server, while symmetric methods like HS256 would still require sharing a secret. +4. **Issue:** If the credentials are valid, your server generates a new JWT with the appropriate claims (`iss`, `aud`, `exp`, etc.). +5. **Sign:** Your server signs the JWT using asymmetric cryptography (e.g., `RS256` with your private key). This is better than symmetric signing because your private key never leaves your server. In contrast, symmetric methods like `HS256` would still require you to share a secret. 6. **Respond:** The signed JWT is returned to the customer as an access token. -7. **Use:** The customer includes this short-lived JWT in API requests. When it expires, they simply request a new one. +7. **Use:** The customer includes this short-lived JWT in their API requests. When it expires, they simply request a new one. ## OAuth2 Token Endpoint Practical Example @@ -72,7 +72,7 @@ Here's what a token request looks like in practice: ```http POST /token HTTP/1.1 -Host: api.example.com +Host: idp.example.com Content-Type: application/x-www-form-urlencoded grant_type=client_credentials @@ -98,42 +98,50 @@ Host: zgw-api.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... ``` -The customer doesn't worry about JWT structure, signing algorithms, or claim management. They simply exchange credentials for a token and use it. +The customer doesn't have to worry about the JWT structure, signing algorithms, or claim management. They simply exchange their credentials for a token and use it. -## So, why the Token Endpoint Model is Better? +## So, why is the Token Endpoint Model Better? -This model makes sure that the responsibility for creating tokens stays with you, the API provider. You are the Issuer (`iss`), and you have full control over the process. +This model ensures that the responsibility for creating tokens stays with you, the API provider. You are the Issuer (`iss`), and you have full control over the process. * **You Maintain All Best Practices** - * **Token Lifetime:** You set how long tokens last. If you decide they expire in 15 minutes, that's what happens. The customer cannot change it. - * **Claims:** Since you create the token, you ensure all claims (`iss`, `aud`, `exp`) are accurate, included, and standardized. - * **Algorithm:** You pick the signing method, such as `RS256`. Customers only need to use the token without knowing how it is signed. + * **Token Lifetime:** You set how long tokens last. If you decide they should expire in 15 minutes, that's what happens. The customer can't change it. + * **Claims:** Since you create the token, you can ensure that all claims (`iss`, `aud`, `exp`) are accurate, included, and standardized. + * **Algorithm:** You choose the signing method, such as `RS256`. Customers only need to use the token; they don't need to know how it's signed. * **Your Private Key Stays Secret** - * The customer's `client_secret` is not a signing key. It's like a password used to request a token. If it gets leaked, the risk is smaller: - * An attacker can request tokens but cannot create them. You can detect and rate-limit this activity. - * You can revoke that `client_id` or rotate credentials. + * The customer's `client_secret` is not a signing key; it's more like a password used to request a token. If it gets leaked, the risk is much smaller: + * An attacker can request tokens but can't create them. You can detect and rate-limit this activity. + * You can revoke that `client_id` or rotate the credentials. * This is much safer than a leaked signing key, which could let an attacker create fake tokens without being noticed. -* **Easier for Your Customer** - * Customers don't need to set up JWT libraries, handle signing keys, or manage claims. Their job is simply to make one HTTP POST request. Any developer can do this in any language without specialized tools. +* **It's Easier for Your Customer** + * Customers don't need to set up JWT libraries, handle signing keys, or manage claims. Their job is simply to make one HTTP `POST` request. Any developer can do this in any language without needing specialized tools. -* **Better Security Controls** - * **Rate Limiting:** Protect the token endpoint with rate limiting to prevent brute-force attacks on client credentials. - * **Token Revocation:** When credentials are compromised, revoke the `client_id` immediately to invalidate all future token requests. - * **Scope-Based Access:** Issue tokens with specific scopes or permissions based on the client, enabling fine-grained access control. - * **Audit Trail:** Log all token requests to detect suspicious patterns or unauthorized access attempts. - * **Short-Lived Tokens:** Enforce brief token lifetimes (15-60 minutes) to minimize the window of opportunity if a token is intercepted. +* **You Get Better Security Controls** + * **Rate Limiting:** You can protect the token endpoint with rate limiting to prevent brute-force attacks on client credentials. + * **Token Revocation:** If credentials are compromised, you can revoke the `client_id` immediately to invalidate all future token requests. + * **Scope-Based Access:** You can issue tokens with specific scopes or permissions based on the client, which allows for fine-grained access control. + * **Audit Trail:** You can log all token requests to detect suspicious patterns or unauthorized access attempts. + * **Short-Lived Tokens:** You can enforce brief token lifetimes (15-60 minutes) to minimize the window of opportunity if a token is intercepted. ## Conclusion JSON Web Tokens are excellent for securely transmitting information. However, creating them is a delicate security task that should not be left to customers. -By using a standard OAuth2 Token Endpoint, you manage your API's security more effectively. You can immediately apply all best practices, keep your important secrets secure, and offer a simpler, stronger, and more professional experience for your developers. +By using a standard OAuth2 Token Endpoint, you can manage your API's security more effectively. You can apply all best practices, keep your important secrets secure, and offer a simpler, stronger, and more professional experience for your developers. -When tokens expire, customers simply request a new one, no complex refresh logic needed for the Client Credentials flow. This keeps integration straightforward while maintaining strong security. +When tokens expire, customers can simply request a new one. No complex refresh logic is needed for the Client Credentials flow, which keeps the integration straightforward while maintaining strong security. -So, please stop making your customers handle security. Centralize token creation will be kept under your control. +## OneGround's Token Endpoint Implementation + +At OneGround, we are committed to providing the most secure and reliable API experience. That's why we are implementing OAuth2 Token Endpoints across our platform and will soon require all customers to generate tokens through this standardized approach. + +By centralizing token creation under our control, we can ensure consistent security practices, eliminate common vulnerabilities, and simplify the integration process for our customers. This means you'll no longer need to manage JWT creation, signing algorithms, or claim validation. You can simply request a token from our endpoint and use it to access our APIs. + +This change reflects our dedication to security best practices and our responsibility as your API provider to handle authentication correctly. We believe this approach benefits everyone: you get a simpler integration process, and we maintain the high security standards that OneGround is known for. + +You can read more about our implementation and how to use the OAuth2 Token Endpoint in our [ClientID Management and JWT Authentication in OneGround](../docs/usage-of-clientids.md) documentation. ## References From d9ab247d6ac45856e87a8a1ab6ef911104592809 Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 14:47:45 +0200 Subject: [PATCH 4/7] Refine language for clarity in OAuth 2.0 Token Endpoint security discussion --- blog/2025-11-14-oauth2-token-endpoint.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index a354341..6a73dba 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -42,7 +42,7 @@ This approach falls short of best practices in several ways: You can suggest a one-hour expiration, but you can't enforce it. A developer might try to "fix" re-authentication issues by setting the `exp` claim to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To fix this, you would need to add complex validation checks, which is a reactive security measure, not a proactive one. * **It Creates Secret Management Issues:** -You have to share a signing secret with your customers, which makes their secret management your security risk. If they leak the secret—by committing it to code, embedding it in an app, or logging it—attackers could create valid tokens forever, impersonating legitimate clients without being detected. +You have to share a signing secret with your customers, which makes their secret management your security risk. If they leak the secret, by committing it to code, embedding it in an app, or logging it, attackers could create valid tokens forever, impersonating legitimate clients without being detected. * **You Have No Control Over Implementation:** You can't ensure that customers are using trusted libraries. They might use outdated or insecure libraries or try to create their own JWTs in a way that isn't secure. This exposes you to attacks like the `alg: "none"` vulnerability, where some JWT libraries might accept unsigned tokens. This would allow attackers to create fake tokens by skipping the signature validation. From 8587edc5c0c11b759a1dac01abd15bc4050319bf Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 14:57:12 +0200 Subject: [PATCH 5/7] Refine language and clarity in OAuth2 Token Endpoint documentation --- blog/2025-11-14-oauth2-token-endpoint.md | 108 +++++++++++------------ 1 file changed, 53 insertions(+), 55 deletions(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index 6a73dba..9074367 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -1,6 +1,6 @@ --- slug: oauth2-token-endpoint -title: "OAuth 2.0 Token Endpoint - OneGround Security Guide" +title: "Why OneGround Uses an OAuth2 Token Endpoint" description: "Learn why customer-generated JWTs are risky and how OAuth2 Token Endpoints provide better security, control, and simplicity for API authentication." authors: giedriusgrabauskas tags: [security] @@ -18,55 +18,53 @@ keywords: - security implementation --- -# OAuth2 Token Endpoint +We have previously published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md), which outlines the standards for creating secure and reliable JSON Web Tokens. It covers essential practices like using proper claims (`iss`, `exp`), managing secrets securely, and keeping tokens short-lived. -We already have published an [article on JWT best practices](./2024-12-03-best-practices-for-jwt-usage-in-apis.md) that explains the rules for creating safe and reliable JSON Web Tokens. It emphasizes using proper claims like `iss` (Issuer) and `exp` (Expiration), securely managing secrets, and keeping tokens short-lived. +This raises an important question: **Who is responsible for implementing these security rules?** -But this raises a key question: **Who should be responsible for following these rules?** +In some API designs, customers are asked to generate their own JWTs. The approach is seemingly straightforward: "Here is a secret key. Please create a JWT according to our guidelines, sign it, and include it in your `Authorization` header." -A risky pattern in API design is letting customers create their own JWTs. The idea seems simple: "Here's a secret key, Mr. Customer. Just make a JWT using our guidelines, sign it with this secret, and include it in your `Authorization` header." +However, this model shifts the complex and critical responsibility of security onto you, the customer. At OneGround, we believe that security should be a shared responsibility, but the burden of token creation should lie with the API provider. This is why we use a standard **OAuth2 Token Endpoint**, which allows you to request a token from us instead of creating one yourself. -This approach shifts the difficult task of security onto the customer, which goes against best practices and can lead to an unstable and insecure system. - -A much better model is to use a standard **OAuth2 Token Endpoint**. Instead of asking your customer to create a token, you let them request one. +This article explains why our approach is more secure, reliable, and ultimately simpler for you. -## The Problems with "Bring Your Own JWT" +## The Problem with "Bring Your Own JWT" -When you allow a customer to create their own JWT, you turn them into an Issuer (`iss`). This means you are relying on them to manage the entire token process safely and correctly. This is often risky, not due to any malicious intent from customers, but because generating tokens is a complex process. +When an API provider asks you to create your own JWT, you become the token issuer (`iss`). This means you are responsible for managing the entire token generation process securely. While this might seem to offer flexibility, it introduces significant risks and complexities, not because of any oversight on your part, but because token generation is a sensitive security function. -This approach falls short of best practices in several ways: +Here are some of the challenges with this model: -* **You Can't Control Token Expiration:** -You can suggest a one-hour expiration, but you can't enforce it. A developer might try to "fix" re-authentication issues by setting the `exp` claim to 10 years. This exposes your API to replay attacks and unauthorized access from long-lived tokens. To fix this, you would need to add complex validation checks, which is a reactive security measure, not a proactive one. +* **Lack of Enforced Token Expiration:** + A critical security practice is to use short-lived tokens. If you were to generate your own tokens, you would be responsible for managing their expiration. While our guidelines might suggest a one-hour expiration, it would be technically possible to create tokens with very long lifetimes, for example, to work around re-authentication logic. Such long-lived tokens would expose your application and our API to security risks, such as replay attacks, if a token is ever compromised. To prevent this, we would need to add complex validation checks on our side, which is a reactive security measure, not a proactive one. -* **It Creates Secret Management Issues:** -You have to share a signing secret with your customers, which makes their secret management your security risk. If they leak the secret, by committing it to code, embedding it in an app, or logging it, attackers could create valid tokens forever, impersonating legitimate clients without being detected. +* **It Creates Secret Management Burdens:** + To enable you to sign JWTs, we would have to share a signing secret with you. This would place the burden of protecting that secret entirely on you. If the secret were accidentally leaked—for instance, by being committed to a code repository, embedded in a client-side application, or logged in plain text—an attacker could create valid tokens indefinitely. This would pose a significant security threat to your integration and data. -* **You Have No Control Over Implementation:** -You can't ensure that customers are using trusted libraries. They might use outdated or insecure libraries or try to create their own JWTs in a way that isn't secure. This exposes you to attacks like the `alg: "none"` vulnerability, where some JWT libraries might accept unsigned tokens. This would allow attackers to create fake tokens by skipping the signature validation. +* **You Have No Control Over the Implementation:** + To generate JWTs, your developers would need to select and use a library for the language of their choice. This introduces the risk of using outdated or insecure libraries that may contain vulnerabilities. For example, some older JWT libraries were susceptible to the `alg: "none"` vulnerability, where they would accept a token without a signature. This would allow an attacker to forge tokens and bypass security checks entirely. * **It Increases API Complexity:** -Your API has to handle validation for tokens from different customer setups, each with its own unique issues. You have to validate every claim (`iss`, `aud`, `exp`) in each request to make sure the customer has implemented it correctly. + In a "bring your own JWT" model, our API would need to perform extensive validation on every single request to check for inconsistencies in how different customers implement their token generation. We would have to defensively validate every claim (`iss`, `aud`, `exp`) to ensure they are correctly implemented, adding overhead and complexity. ## The Secure and Simple Alternative: The OAuth2 Token Endpoint -The OAuth2 framework, particularly the **Client Credentials Grant** flow, offers a simple and standardized solution. +The OAuth2 framework, specifically the **Client Credentials Grant** flow, provides a standardized and much more secure solution that we use at OneGround. -Here's how it works: +Here’s how it works: -1. **Request:** The customer (client) sends a secure HTTPS `POST` request to your token endpoint (e.g., `/oauth/token`). -2. **Credentials:** In this request, they include the `client_id` and `client_secret` that you provided. -3. **Validate:** Your server validates these credentials against your secure credential store. -4. **Issue:** If the credentials are valid, your server generates a new JWT with the appropriate claims (`iss`, `aud`, `exp`, etc.). -5. **Sign:** Your server signs the JWT using asymmetric cryptography (e.g., `RS256` with your private key). This is better than symmetric signing because your private key never leaves your server. In contrast, symmetric methods like `HS256` would still require you to share a secret. -6. **Respond:** The signed JWT is returned to the customer as an access token. -7. **Use:** The customer includes this short-lived JWT in their API requests. When it expires, they simply request a new one. +1. **Request:** Your application sends a secure HTTPS `POST` request to our token endpoint (e.g., `/oauth/token`). +2. **Credentials:** In this request, you include the `client_id` and `client_secret` that we provide to you. +3. **Validation:** Our server validates these credentials against our secure credential store. +4. **Issuance:** If the credentials are valid, our server generates a new JWT with all the correct claims (`iss`, `aud`, `exp`, etc.). +5. **Signing:** Our server signs the JWT using a secure, asymmetric algorithm (like `RS256`) with our private key. This key never leaves our server, which is a major security advantage over sharing a secret with you. +6. **Response:** The signed JWT is returned to your application as an access token. +7. **Usage:** Your application includes this short-lived JWT in the `Authorization` header of your API requests. When it expires, you simply request a new one. ## OAuth2 Token Endpoint Practical Example -Here's what a token request looks like in practice: +Here’s what a token request and its usage look like in practice: **Request:** @@ -98,48 +96,48 @@ Host: zgw-api.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... ``` -The customer doesn't have to worry about the JWT structure, signing algorithms, or claim management. They simply exchange their credentials for a token and use it. +With this model, you don't have to worry about the internal structure of the JWT, signing algorithms, or claim management. You simply exchange your credentials for a ready-to-use token. -## So, why is the Token Endpoint Model Better? +## Why the Token Endpoint Model is Better for You -This model ensures that the responsibility for creating tokens stays with you, the API provider. You are the Issuer (`iss`), and you have full control over the process. +This model ensures that the responsibility for creating secure tokens remains with us, the API provider. As the issuer (`iss`), we have full control over the security of the token generation process. -* **You Maintain All Best Practices** - * **Token Lifetime:** You set how long tokens last. If you decide they should expire in 15 minutes, that's what happens. The customer can't change it. - * **Claims:** Since you create the token, you can ensure that all claims (`iss`, `aud`, `exp`) are accurate, included, and standardized. - * **Algorithm:** You choose the signing method, such as `RS256`. Customers only need to use the token; they don't need to know how it's signed. +* **We Maintain All Best Practices on Your Behalf** + * **Token Lifetime:** We set and enforce how long tokens are valid. If we decide they should expire in 15 minutes for security reasons, that is enforced for everyone. You don't have to worry about it. + * **Claims:** Because we create the token, we guarantee that all necessary claims (`iss`, `aud`, `exp`) are accurate, present, and standardized. + * **Algorithm:** We choose and manage the signing algorithm, such as the industry-standard `RS256`. Your application only needs to use the token, not understand its cryptographic implementation. -* **Your Private Key Stays Secret** - * The customer's `client_secret` is not a signing key; it's more like a password used to request a token. If it gets leaked, the risk is much smaller: - * An attacker can request tokens but can't create them. You can detect and rate-limit this activity. - * You can revoke that `client_id` or rotate the credentials. - * This is much safer than a leaked signing key, which could let an attacker create fake tokens without being noticed. +* **Our Private Signing Key Stays Secret** + * The `client_secret` we provide you is not a signing key; it functions more like a password for your application to authenticate itself when requesting a token. The risk of a leak is significantly lower: + * An attacker with a leaked `client_secret` can only request tokens, not create them. We can detect and rate-limit this activity. + * We can quickly revoke a compromised `client_id` or rotate your credentials without affecting the entire system's security. + * This is far more secure than a leaked signing key, which would allow an attacker to forge valid tokens undetected. -* **It's Easier for Your Customer** - * Customers don't need to set up JWT libraries, handle signing keys, or manage claims. Their job is simply to make one HTTP `POST` request. Any developer can do this in any language without needing specialized tools. +* **It's Easier for Your Developers** + * Your developers don't need to research JWT libraries, manage signing keys, or worry about getting security claims right. Their only task is to make a single, standard HTTP `POST` request. This is a common task that any developer can implement in any language without specialized security knowledge. -* **You Get Better Security Controls** - * **Rate Limiting:** You can protect the token endpoint with rate limiting to prevent brute-force attacks on client credentials. - * **Token Revocation:** If credentials are compromised, you can revoke the `client_id` immediately to invalidate all future token requests. - * **Scope-Based Access:** You can issue tokens with specific scopes or permissions based on the client, which allows for fine-grained access control. - * **Audit Trail:** You can log all token requests to detect suspicious patterns or unauthorized access attempts. - * **Short-Lived Tokens:** You can enforce brief token lifetimes (15-60 minutes) to minimize the window of opportunity if a token is intercepted. +* **You Benefit from Better Security Controls** + * **Rate Limiting:** We protect our token endpoint with rate limiting to prevent brute-force attacks on client credentials. + * **Token Revocation:** If your credentials are ever compromised, we can revoke your `client_id` immediately, cutting off all future token requests from that ID. + * **Scope-Based Access:** We can issue tokens with specific permissions (scopes) based on your client's needs, ensuring your application has only the access it requires (the principle of least privilege). + * **Audit Trails:** We maintain logs of all token requests, allowing us to detect suspicious patterns and investigate potential unauthorized access attempts. + * **Short-Lived Tokens:** We enforce short token lifetimes (e.g., 15-60 minutes) to minimize the risk if a token is ever intercepted. ## Conclusion -JSON Web Tokens are excellent for securely transmitting information. However, creating them is a delicate security task that should not be left to customers. +JSON Web Tokens are an excellent standard for securely transmitting information in APIs. However, the creation of these tokens is a sensitive security function that should be managed by the API provider, not the customer. -By using a standard OAuth2 Token Endpoint, you can manage your API's security more effectively. You can apply all best practices, keep your important secrets secure, and offer a simpler, stronger, and more professional experience for your developers. +By using a standard OAuth2 Token Endpoint, we provide a more secure and reliable authentication system. We handle the complexities of token generation, allowing you to focus on building your application. This approach simplifies development, reduces security risks, and ensures that best practices are followed consistently. -When tokens expire, customers can simply request a new one. No complex refresh logic is needed for the Client Credentials flow, which keeps the integration straightforward while maintaining strong security. +When a token expires, your application simply requests a new one. For the Client Credentials flow, this is a straightforward process that does not require complex refresh token logic, keeping your integration simple while maintaining a high level of security. -## OneGround's Token Endpoint Implementation +## OneGround's Commitment to Secure Authentication -At OneGround, we are committed to providing the most secure and reliable API experience. That's why we are implementing OAuth2 Token Endpoints across our platform and will soon require all customers to generate tokens through this standardized approach. +At OneGround, we are committed to providing the most secure and reliable API experience. That's why we have implemented an OAuth2 Token Endpoint across our platform and require all customers to generate tokens through this standardized and secure approach. -By centralizing token creation under our control, we can ensure consistent security practices, eliminate common vulnerabilities, and simplify the integration process for our customers. This means you'll no longer need to manage JWT creation, signing algorithms, or claim validation. You can simply request a token from our endpoint and use it to access our APIs. +By centralizing token creation, we ensure consistent security practices for all our customers, eliminate common vulnerabilities associated with client-side token generation, and simplify the integration process for your development teams. You no longer need to worry about JWT creation, signing algorithms, or claim validation. Instead, you can confidently and easily request a token from our endpoint to access our APIs. -This change reflects our dedication to security best practices and our responsibility as your API provider to handle authentication correctly. We believe this approach benefits everyone: you get a simpler integration process, and we maintain the high security standards that OneGround is known for. +This approach reflects our dedication to security best practices and our responsibility as your API provider to handle authentication correctly. We believe this model benefits everyone: you get a simpler and more secure integration, and we maintain the high security standards that OneGround is known for. You can read more about our implementation and how to use the OAuth2 Token Endpoint in our [ClientID Management and JWT Authentication in OneGround](../docs/usage-of-clientids.md) documentation. From 7310c9f3d8d44bc99598c18c322af3d3e0809679 Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 15:01:51 +0200 Subject: [PATCH 6/7] Formatting --- blog/2025-11-14-oauth2-token-endpoint.md | 72 ++++++++++++------------ 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index 9074367..073cd64 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -36,16 +36,16 @@ When an API provider asks you to create your own JWT, you become the token issue Here are some of the challenges with this model: -* **Lack of Enforced Token Expiration:** +- **Lack of Enforced Token Expiration:** A critical security practice is to use short-lived tokens. If you were to generate your own tokens, you would be responsible for managing their expiration. While our guidelines might suggest a one-hour expiration, it would be technically possible to create tokens with very long lifetimes, for example, to work around re-authentication logic. Such long-lived tokens would expose your application and our API to security risks, such as replay attacks, if a token is ever compromised. To prevent this, we would need to add complex validation checks on our side, which is a reactive security measure, not a proactive one. -* **It Creates Secret Management Burdens:** +- **It Creates Secret Management Burdens:** To enable you to sign JWTs, we would have to share a signing secret with you. This would place the burden of protecting that secret entirely on you. If the secret were accidentally leaked—for instance, by being committed to a code repository, embedded in a client-side application, or logged in plain text—an attacker could create valid tokens indefinitely. This would pose a significant security threat to your integration and data. -* **You Have No Control Over the Implementation:** +- **You Have No Control Over the Implementation:** To generate JWTs, your developers would need to select and use a library for the language of their choice. This introduces the risk of using outdated or insecure libraries that may contain vulnerabilities. For example, some older JWT libraries were susceptible to the `alg: "none"` vulnerability, where they would accept a token without a signature. This would allow an attacker to forge tokens and bypass security checks entirely. -* **It Increases API Complexity:** +- **It Increases API Complexity:** In a "bring your own JWT" model, our API would need to perform extensive validation on every single request to check for inconsistencies in how different customers implement their token generation. We would have to defensively validate every claim (`iss`, `aud`, `exp`) to ensure they are correctly implemented, adding overhead and complexity. ## The Secure and Simple Alternative: The OAuth2 Token Endpoint @@ -82,9 +82,9 @@ grant_type=client_credentials ```json { - "access_token": "eyJhbGciOi...", - "token_type": "Bearer", - "expires_in": 3600 + "access_token": "eyJhbGciOi...", + "token_type": "Bearer", + "expires_in": 3600 } ``` @@ -102,26 +102,26 @@ With this model, you don't have to worry about the internal structure of the JWT This model ensures that the responsibility for creating secure tokens remains with us, the API provider. As the issuer (`iss`), we have full control over the security of the token generation process. -* **We Maintain All Best Practices on Your Behalf** - * **Token Lifetime:** We set and enforce how long tokens are valid. If we decide they should expire in 15 minutes for security reasons, that is enforced for everyone. You don't have to worry about it. - * **Claims:** Because we create the token, we guarantee that all necessary claims (`iss`, `aud`, `exp`) are accurate, present, and standardized. - * **Algorithm:** We choose and manage the signing algorithm, such as the industry-standard `RS256`. Your application only needs to use the token, not understand its cryptographic implementation. +- **We Maintain All Best Practices on Your Behalf** + - **Token Lifetime:** We set and enforce how long tokens are valid. If we decide they should expire in 15 minutes for security reasons, that is enforced for everyone. You don't have to worry about it. + - **Claims:** Because we create the token, we guarantee that all necessary claims (`iss`, `aud`, `exp`) are accurate, present, and standardized. + - **Algorithm:** We choose and manage the signing algorithm, such as the industry-standard `RS256`. Your application only needs to use the token, not understand its cryptographic implementation. -* **Our Private Signing Key Stays Secret** - * The `client_secret` we provide you is not a signing key; it functions more like a password for your application to authenticate itself when requesting a token. The risk of a leak is significantly lower: - * An attacker with a leaked `client_secret` can only request tokens, not create them. We can detect and rate-limit this activity. - * We can quickly revoke a compromised `client_id` or rotate your credentials without affecting the entire system's security. - * This is far more secure than a leaked signing key, which would allow an attacker to forge valid tokens undetected. +- **Our Private Signing Key Stays Secret** + - The `client_secret` we provide you is not a signing key; it functions more like a password for your application to authenticate itself when requesting a token. The risk of a leak is significantly lower: + - An attacker with a leaked `client_secret` can only request tokens, not create them. We can detect and rate-limit this activity. + - We can quickly revoke a compromised `client_id` or rotate your credentials without affecting the entire system's security. + - This is far more secure than a leaked signing key, which would allow an attacker to forge valid tokens undetected. -* **It's Easier for Your Developers** - * Your developers don't need to research JWT libraries, manage signing keys, or worry about getting security claims right. Their only task is to make a single, standard HTTP `POST` request. This is a common task that any developer can implement in any language without specialized security knowledge. +- **It's Easier for Your Developers** + - Your developers don't need to research JWT libraries, manage signing keys, or worry about getting security claims right. Their only task is to make a single, standard HTTP `POST` request. This is a common task that any developer can implement in any language without specialized security knowledge. -* **You Benefit from Better Security Controls** - * **Rate Limiting:** We protect our token endpoint with rate limiting to prevent brute-force attacks on client credentials. - * **Token Revocation:** If your credentials are ever compromised, we can revoke your `client_id` immediately, cutting off all future token requests from that ID. - * **Scope-Based Access:** We can issue tokens with specific permissions (scopes) based on your client's needs, ensuring your application has only the access it requires (the principle of least privilege). - * **Audit Trails:** We maintain logs of all token requests, allowing us to detect suspicious patterns and investigate potential unauthorized access attempts. - * **Short-Lived Tokens:** We enforce short token lifetimes (e.g., 15-60 minutes) to minimize the risk if a token is ever intercepted. +- **You Benefit from Better Security Controls** + - **Rate Limiting:** We protect our token endpoint with rate limiting to prevent brute-force attacks on client credentials. + - **Token Revocation:** If your credentials are ever compromised, we can revoke your `client_id` immediately, cutting off all future token requests from that ID. + - **Scope-Based Access:** We can issue tokens with specific permissions (scopes) based on your client's needs, ensuring your application has only the access it requires (the principle of least privilege). + - **Audit Trails:** We maintain logs of all token requests, allowing us to detect suspicious patterns and investigate potential unauthorized access attempts. + - **Short-Lived Tokens:** We enforce short token lifetimes (e.g., 15-60 minutes) to minimize the risk if a token is ever intercepted. ## Conclusion @@ -143,15 +143,15 @@ You can read more about our implementation and how to use the OAuth2 Token Endpo ## References -* [RFC 6749: The official specification for OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) -* [RFC 7519: JSON Web Token (JWT) specification](https://datatracker.ietf.org/doc/html/rfc7519) -* [RFC 8252: OAuth 2.0 for Native Apps - Best Current Practice](https://datatracker.ietf.org/doc/html/rfc8252) -* [RFC 6819: OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) -* [BCP: OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) -* [OWASP: OAuth 2.0 Protocol Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) -* [OWASP: JSON Web Token Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) -* [OWASP: WSTG Testing for OAuth Weaknesses](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/) -* [auth0.com: Critical vulnerabilities in JSON Web Token libraries](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) -* [JWT.io: Introduction to JSON Web Tokens: A beginner-friendly guide to understanding JWTs](https://jwt.io/introduction) -* [oauth.com: OAuth 2.0 Simplified](https://www.oauth.com/) -* [oauth.com: Client Credentials, OAuth 2.0 Simplified](https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/) +- [RFC 6749: The official specification for OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +- [RFC 7519: JSON Web Token (JWT) specification](https://datatracker.ietf.org/doc/html/rfc7519) +- [RFC 8252: OAuth 2.0 for Native Apps - Best Current Practice](https://datatracker.ietf.org/doc/html/rfc8252) +- [RFC 6819: OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) +- [BCP: OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) +- [OWASP: OAuth 2.0 Protocol Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) +- [OWASP: JSON Web Token Security Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) +- [OWASP: WSTG Testing for OAuth Weaknesses](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/) +- [auth0.com: Critical vulnerabilities in JSON Web Token libraries](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) +- [JWT.io: Introduction to JSON Web Tokens: A beginner-friendly guide to understanding JWTs](https://jwt.io/introduction) +- [oauth.com: OAuth 2.0 Simplified](https://www.oauth.com/) +- [oauth.com: Client Credentials, OAuth 2.0 Simplified](https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/) From e85a5b7bbfbc731c44ee7252a0cb5ccd818b8fca Mon Sep 17 00:00:00 2001 From: Giedrius Grabauskas <43740166+Grabauskas@users.noreply.github.com> Date: Fri, 14 Nov 2025 15:04:06 +0200 Subject: [PATCH 7/7] Fix link to ClientID Management documentation in OAuth2 Token Endpoint article --- blog/2025-11-14-oauth2-token-endpoint.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/2025-11-14-oauth2-token-endpoint.md b/blog/2025-11-14-oauth2-token-endpoint.md index 073cd64..0b5c415 100644 --- a/blog/2025-11-14-oauth2-token-endpoint.md +++ b/blog/2025-11-14-oauth2-token-endpoint.md @@ -139,7 +139,7 @@ By centralizing token creation, we ensure consistent security practices for all This approach reflects our dedication to security best practices and our responsibility as your API provider to handle authentication correctly. We believe this model benefits everyone: you get a simpler and more secure integration, and we maintain the high security standards that OneGround is known for. -You can read more about our implementation and how to use the OAuth2 Token Endpoint in our [ClientID Management and JWT Authentication in OneGround](../docs/usage-of-clientids.md) documentation. +You can read more about our implementation and how to use the OAuth2 Token Endpoint in our [ClientID Management and JWT Authentication in OneGround](../docs/usage-of-clientids) documentation. ## References