# oauth 2.0 Published articles for oauth 2.0. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Step-by-Step Guide to eBay API Integration With AI Agents DevFeed: [A Step-by-Step Guide to eBay API Integration With AI Agents]() Original publisher: [Read original article]() Author: Mat Banik Published: 2026-11-08T20:48:16Z Content type: tutorial Language: en Sources: [HackerNoon]() Topics: [Loop Engineering](), [human in the loop agent](), [API]() Tags: [account](), [adoption](), [agent](), [agents](), [agents-md](), [ai](), [ai-agent](), [ai-agents](), [ai-coding](), [ai-coding-agent](), [ai-coding-agents](), [api](), [api-access](), [api-integration](), [claude](), [claude-code](), [ebay](), [ebay-api](), [ebay-oauth](), [ebay-seller-api](), [ecommerce-automation](), [guide](), [keys](), [oauth-2-0](), [production](), [setup]() ### AI overview The guide connects an AI listing agent to an eBay Production seller account through a split workflow: the person creates developer credentials, unlocks the keyset, publishes a privacy policy, creates a RuName, supplies secrets locally, completes seller consent, and creates business policies; the agent handles the remaining setup and API checks. The refresh token stays in a local `.env` file. Listings remain unpublished until the seller explicitly confirms publishing, and account-changing setup commands also require confirmation. The guide chooses Production because Sandbox accounts lack the seller policies and inventory location the pipeline needs, but warns that this connects to a real account. It is written for the US marketplace and says other marketplaces are untested. Production activation may require an account deletion exemption; if no truthful exemption applies or it is denied, the guide says an HTTPS notification endpoint must be hosted. Labels may change, and eBay approval can take about one business day. ### Source excerpt eBay API setup for an AI listing agent, in Production. You click six eBay pages and paste three keys. Your agent runs the rest of the steps. ## Keycloak's observability journey: a guide for project maintainers DevFeed: [Keycloak's observability journey: a guide for project maintainers]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-11-02T15:39:10Z Content type: article Language: en Sources: [OpenTelemetry]() Topics: [OpenTelemetry](), [observability](), [Keycloak](), [Prometheus]() Tags: [access-management](), [cncf](), [guide](), [iam](), [identity-and-access-management](), [interviews](), [keycloak](), [maintainers](), [oauth](), [oauth-2-0](), [observability](), [oidc](), [open-source](), [openid-connect](), [opentelemetry](), [saml]() ### AI overview Keycloak's maintainers found that the OpenTelemetry Java agent enabled quick experimentation but added dozens of seconds to startup, so they moved to native Quarkus integration to preserve fast startup. Metrics gave immediate value; tracing helped locate database and LDAP bottlenecks, and exemplars linked metric spikes to representative traces for investigating high-percentile latency. OpenTelemetry support is on by default, but users must enable a component such as tracing to export data. The source also flags operational tradeoffs: unlike pull-based Prometheus, push-based telemetry over an open TCP socket lacks built-in backpressure and raises questions about signal origin and overload. Keycloak uses custom identity-provider attribute prefixes because conventions are not standardized, and its maintainers call for clearer guides and validation tools such as Weaver. ### Source excerpt As part of an ongoing series, the Developer Experience SIG interviews organizations about their real-world OpenTelemetry deployments to share practical lessons with the broader community. This post features Keycloak, a CNCF project, and looks at the journey from the perspective of project maintainers who add native OpenTelemetry support to the software they ship. If you have ever needed an Identity and Access Management (IAM) solution, there is a good chance Keycloak was on your radar: a widely used, community-driven open source IAM system that secures applications by authenticating both human and non-human users through industry-standard protocols such as OpenID Connect (OIDC), OAuth 2.0, and SAML. ## Google Adopts DPoP to Strengthen OAuth 2.0 Against Token Theft and Replay Attacks DevFeed: [Google Adopts DPoP to Strengthen OAuth 2.0 Against Token Theft and Replay Attacks]() Original publisher: [Read original article]() Author: Sergio De Simone Published: 2026-10-29T19:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [OAuth 2.0](), [Credential theft](), [credential-based attacks](), [Secure token management](), [frontend security]() Tags: [adversary](), [adversary-in-the-middle-aitm](), [agent](), [agent-workflows](), [api](), [architecture-design](), [bearer](), [browser](), [client](), [cloud](), [cloud-security](), [cookies](), [credential-theft](), [credentials](), [cryptographic](), [cryptography](), [development](), [google](), [google-dpop-oauth2](), [news](), [oauth](), [oauth-2-0](), [proof-of-possession](), [security](), [theft](), [token]() ### AI overview Google OAuth supports DPoP for refresh tokens, binding them to a client-generated asymmetric key so a stolen token cannot be replayed without the private key. Access tokens remain bearer tokens; the text says applying DPoP to each request would add cryptographic verification overhead. Clients must manage keys, timestamps, nonces, HTTP headers and DPoP proof JWTs. DPoP does not protect web session cookies; Google and WICG are developing DBSC to bind browser cookies to device hardware. For multi-agent delegation, the text points to Google Cloud STS to exchange an upstream token for a short-lived federated token bound to the next agent's key. Because browser-held keys remain exposed to client-side misuse, the cited IETF guidance recommends a Backend-for-Frontend pattern; a zero-persistence approach is also proposed where server infrastructure is unavailable. ### Source excerpt Google's OAuth Platform has recently introduces support for Demonstrating Proof-of-Possession (DPoP), an OAuth 2.0 security mechanism designed to mitigate token theft and replay attacks. By Sergio De Simone ## How I Have Implemented SSO Authentication in ? DevFeed: [How I Have Implemented SSO Authentication in ?]() Original publisher: [Read original article]() Author: Devops Diaries Published: 2026-10-16T09:12:06Z Content type: tutorial Language: en Sources: [DevOps.dev]() Topics: [Single sign-on (SSO)](), [Authentication]() Tags: [authentication](), [authorization](), [azure](), [azure-devops](), [devops](), [devops-diaries](), [microsoft-azure](), [oauth-2-0](), [openid-connect](), [sso]() ### AI overview The excerpt recommends Authorization Code flow with OpenID Connect for a server-side web app hosted in Azure, assuming the identity provider supports OAuth 2.0/OIDC. The stated aim is to let users sign in through an existing identity provider using SSO. Further integration steps and lessons are not included in the supplied excerpt. ### Source excerpt Implementing authentication is always a critical step in any application -- it defines how securely and seamlessly users can access your... Continue reading on DevOps.dev " ## Build a Secure TypeScript MCP Client with Cross App Access (XAA) DevFeed: [Build a Secure TypeScript MCP Client with Cross App Access (XAA)]() Original publisher: [Read original article]() Author: Akanksha Bhasin Published: 2026-10-09T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [cross-app-access](), [MSP MCP](), [OpenID connect (OIDC)](), [Test-driven development]() Tags: [cross-app-access](), [jwt](), [mcp](), [mcp-server](), [node](), [node-js](), [npm](), [oauth](), [oauth-2-0](), [oidc](), [typescript](), [xaa]() ### AI overview A TypeScript tutorial builds an MCP requesting app that uses Cross App Access to obtain delegated access to a protected resource. It walks through the OAuth and token exchange steps, explains ID-JAG claims, and configures the MCP TypeScript SDK's CrossAppAccessProvider, including authentication and scope adjustments for the xaa.dev playground. ### Source excerpt Enterprise apps rarely work alone. Imagine this scenario: HR wants to ensure that a new employee completes their new hire onboarding, and they want this verification in the company's HR app so it's tied to the employee's personnel file. But the onboarding tasks come from a task-tracking tool with requirements defined by each department, from a different vendor and on a different domain than the HR app. It's on IT to bridge the two. Wiring the two together normally costs the user an OAuth consent screen or costs IT a shared service account. Cross App Access (XAA) removes that step. The company's identity provider vouches for the user across the boundary, under a policy the admin sets in advance. In this tutorial, you'll build that flow end-to-end in TypeScript. You'll build a Model Context Protocol (MCP) requesting app: a web app that signs a user in through an enterprise Identity Provider (IdP), exchanges that identity for a delegation token called an Identity Assertion JWT Authorization Grant (ID-JAG), trades the ID-JAG for an access token, and calls a protected MCP server to fetch real data. You'll use the MCP TypeScript SDK, which added first-class Cross App Access support, and you'll test everything against xaa.dev, the free XAA playground from the Okta Dev Advocacy team. By the end of this post, you can: Explain what XAA is and why AI agents and enterprise apps need it Read an ID-JAG and understand key claims in it Understand each step of the XAA flow through the SDK functions Let the SDK's CrossAppAccessProvider run the whole flow for you Prerequisites Node.js 20 or later npm, which ships with Node.js A free xaa.dev registration (email only) Familiarity with OAuth 2.0 concepts. If Proof Key for Code Exchange (PKCE) is new to you, read Secure Your Express App with OAuth 2.0, OIDC, and PKCE first. The code in this tutorial runs against @modelcontextprotocol/client version 2.0.0-alpha.2, openid-client 6, Express 4, and the xaa.dev playground services. The MCP SDK ## Apache Polaris with OIDC: Keycloak, Okta, and External Identity Providers DevFeed: [Apache Polaris with OIDC: Keycloak, Okta, and External Identity Providers]() Original publisher: [Read original article]() Author: Alex Merced Published: 2026-09-25T12:43:05Z Content type: tutorial Language: en Sources: [Dremio]() Topics: [OpenID connect (OIDC)](), [Authentication](), [Authorization](), [JSON Web Tokens](), [Keycloak](), [okta](), [OAuth 2.0]() Tags: [apache-iceberg](), [apache-polaris](), [authentication](), [authorization](), [data-lakehouse](), [dremio-blog-open-data-insights](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [okta]() ### AI overview A practical guide to configuring Apache Polaris with external OpenID Connect identity providers. It explains token validation, claim-to-role mapping, issuer and audience checks, JWKS verification, and production troubleshooting, with examples for Keycloak and Okta. ### Source excerpt Configure Apache Polaris with an external OIDC provider, map claims to principals and roles, rotate keys, and troubleshoot Keycloak or Okta authentication. The post Apache Polaris with OIDC: Keycloak, Okta, and External Identity Providers appeared first on Dremio. ## Caching Cognito M2M Tokens With Lambda, DynamoDB, and WAF DevFeed: [Caching Cognito M2M Tokens With Lambda, DynamoDB, and WAF]() Original publisher: [Read original article]() Author: Lucas Tonelli Published: 2026-09-24T17:00:19Z Content type: tutorial Language: en Sources: [HackerNoon]() Topics: [Amazon Web Services](), [Authentication](), [OAuth 2.0](), [Amazon API Gateway]() Tags: [access-token-caching](), [api-gateway](), [authentication](), [aws](), [aws-cognito](), [aws-cost-optimization](), [aws-lambda](), [aws-waf](), [caching](), [costs](), [dynamodb](), [dynamodb-ttl](), [lambda](), [m2m-authentication](), [oauth](), [oauth-2-0](), [oauth2-client-credentials](), [tokens](), [waf]() ### AI overview The tutorial describes placing a Lambda function between services and Amazon Cognito to cache machine-to-machine OAuth 2.0 access tokens in DynamoDB. It explains how expiry checks, TTL, scope-aware keys, and AWS WAF can reduce repeated token requests and related costs. ### Source excerpt A Lambda in front of Cognito's token endpoint caches tokens in DynamoDB, reducing the number of requests to Cognito and saving money. By adding AWS WAF to block direct requests to Cognito, the solution ensures that all requests go through the Lambda, further reducing costs. ## How device code phishing gives scammers access to your account DevFeed: [How device code phishing gives scammers access to your account]() Original publisher: [Read original article]() Author: Pieter Arntz Published: 2026-09-23T18:59:38Z Content type: tutorial Language: en Sources: [Malwarebytes]() Topics: [OAuth 2.0](), [Social engineering](), [Authentication](), [Authorization](), [MFA](), [JSON Web Tokens]() Tags: [authentication](), [authorization](), [device-code-phishing](), [how-to](), [mfa](), [oauth-2-0](), [phishing](), [social-engineering](), [tokens]() ### AI overview This article explains how device code phishing tricks victims into approving a legitimate sign-in request initiated by an attacker. It describes the OAuth 2.0 Device Authorization Grant, the role of social engineering, the resulting authentication tokens, and why MFA may not prevent the attack. ### Source excerpt A scammer asks you to enter a code to open a file or join a meeting. Approving it could sign them in to your account instead. ## EvilTokens PhaaS disrupted after compromising 12,000 Microsoft accounts DevFeed: [EvilTokens PhaaS disrupted after compromising 12,000 Microsoft accounts]() Original publisher: [Read original article]() Author: Bill Toulas Published: 2026-09-22T15:00:00Z Content type: news Language: en Sources: [BleepingComputer]() Topics: [Microsoft](), [OAuth 2.0](), [Authentication](), [MFA](), [OAuth](), [Authorization](), [Artificial Intelligence]() Tags: [authentication](), [authorization](), [computer-help](), [computer-security](), [computers](), [device-code](), [device-code-phishing](), [disrupted](), [disruption](), [eviltokens](), [infosec](), [infosec-computer-security](), [law-enforcement](), [linux](), [mac](), [malware](), [malware-removal](), [mfa](), [microsoft](), [oauth](), [oauth-2-0](), [phaas](), [phishing](), [phishing-as-a-service](), [report](), [security](), [spycloud](), [spyware](), [support](), [takedown](), [tech-support](), [technical-support](), [tokens](), [virus](), [virus-removal](), [windows]() ### AI overview Microsoft says the EvilTokens phishing-as-a-service platform was disrupted after compromising more than 12,000 Microsoft accounts across over 10,000 organizations. The operation used device-code phishing and AI-powered features, and two suspected administrators were arrested in the U.K. ### Source excerpt The EvilTokens platform that compromised more than 12,000 Microsoft accounts at over 10,000 organizations has been disrupted in an effort led by Microsoft's Digital Crimes Unit (DCU). [...] ## GhostCode attackers abuse device codes to take over Microsoft 365 accounts DevFeed: [GhostCode attackers abuse device codes to take over Microsoft 365 accounts]() Original publisher: [Read original article]() Author: Shweta Sharma Published: 2026-09-18T15:16:22Z Content type: news Language: en Sources: [Computerworld]() Topics: [microsoft 365](), [OAuth 2.0](), [Social engineering](), [Authentication](), [Entra ID](), [MFA](), [API](), [Internet of things]() Tags: [access-control](), [access-control-authentication-cybercrime-identity-and-access-management-microsoft-microsoft-365](), [active-directory](), [auth](), [authentication](), [cybercrime](), [identity-and-access-management](), [microsoft](), [microsoft-365](), [microsoft-graph](), [oauth-2-0](), [phishing](), [security](), [social-engineering](), [tokens]() ### AI overview Computerworld reports that the GhostCode phishing kit abuses Microsoft's OAuth 2.0 device authorization flow to trick Microsoft 365 users into authenticating an attacker-controlled device. Stolen tokens are used to register devices, obtain credentials, and establish persistence in the victim's Microsoft environment. ### Source excerpt Microsoft 365 users are being tricked into handing over access to their accounts by a new phishing kit, GhostCode, that exploits a weakness in a legitimate device authorization flow. Researchers in eSentire's threat response unit identified the campaign in late August 2026. The kit abuses Microsoft's OAuth 2.0 device authorization grant flow, a legitimate mechanism designed to enable authentication from IoT devices, smart TVs, printers, or other devices that cannot easily support a conventional browser-based login. The technique, known as device-code phishing, has been seen in other attacks before. As part of the flow, the device displays a code for the user to enters in a browser on another device to complete authentication. GhostCode poses as one such device, gets Microsoft's OAuth to generate a device code and then convinces the victim to enter it on Microsoft's authentication page. The victim then signs in and completes multifactor authentication as normal -- but the authentication is for the attacker-controlled device, allowing them to obtain the resulting authentication tokens. These tokens are then used to register attacker-controlled devices, obtain additional credentials and establish persistence in the victim's Microsoft environment. In the campaign observed by eSentire, the attack involved a social-engineering setup where attackers pose as procurement officers through a web contact form before moving conversations to an NDA-themed HTML file. Opening the file took the victim to the device-code phishing page. Stolen tokens allow persistence GhostCode's post-authentication activity is focused on turning the stolen access into persistence inside the Microsoft environment. Once access was granted, eSentire recorded nine successful API calls over a 78-second period, involving Microsoft Intune Enrollment, the Device Registration Service, Azure Active Directory and Microsoft Graph. Three devices were registered during that time, at 28, 53 and 77 seconds after auth ## OpenID Connect Authentication for MySQL, Now Fully Open Source DevFeed: [OpenID Connect Authentication for MySQL, Now Fully Open Source]() Original publisher: [Read original article]() Author: Michał Jankowski Published: 2026-09-02T08:56:26Z Content type: article Language: en Sources: [Percona]() Topics: [MySQL](), [OpenID connect (OIDC)](), [Authentication](), [JSON Web Tokens](), [OAuth](), [Open Source]() Tags: [authentication](), [jwks](), [jwt](), [mysql](), [oauth](), [oauth-2-0](), [oidc](), [open-source](), [openid-connect](), [percona](), [percona-server-for-mysql](), [percona-software](), [security]() ### AI overview Percona Server for MySQL includes an open-source OpenID Connect authentication plugin for specified 8.4 and 9.7 releases. The article explains how it authenticates users through standards-compliant identity providers and describes capabilities beyond the MySQL Enterprise plugin, including JWKS signing-key synchronization, group-to-role mapping, and proxy-user support. ### Source excerpt Percona Server for MySQL now ships with a fully open source OpenID Connect (OIDC) authentication plugin, available starting with Percona Server for MySQL 8.4.11-11 and 9.7.2-2 (not yet released as of this writing). It allows a MySQL account to authenticate against any standards-compliant Identity Provider (IdP) instead of relying on a locally stored password, closing ... Continued The post OpenID Connect Authentication for MySQL, Now Fully Open Source appeared first on Percona. ## Your app is the other half of agent SSO DevFeed: [Your app is the other half of agent SSO]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-31T20:22:53Z Content type: opinion Language: en Sources: [WorkOS]() Topics: [Single sign-on (SSO)](), [Authorization](), [JSON Web Tokens](), [OAuth 2.0](), [computer-use]() Tags: [ai-agents](), [app](), [authorization](), [jwt](), [oauth-2-0](), [security](), [sso]() ### AI overview This commentary explains that Okta's Agent SSO and the Cross App Access standard broker connections between AI agents and enterprise applications, but the connected application remains responsible for validating the grant and issuing its own access token. It describes the resource-side roles and the underlying OAuth and JWT-based standards. ### Source excerpt Okta's Agent SSO went GA on the Cross App Access standard. The IdP brokers the connection, but your app still has to validate the grant and issue the token. ## Type-Safe Authentication in Rust with Auth0 and Axum DevFeed: [Type-Safe Authentication in Rust with Auth0 and Axum]() Original publisher: [Read original article]() Author: Aniket Bhattacharyea Published: 2026-08-31T00:00:00Z Content type: tutorial Language: en Sources: [Auth0 Blog]() Topics: [Authentication](), [Auth0](), [Rust](), [Command-line interface](), [OAuth 2.0](), [Authorization](), [API]() Tags: [api](), [auth0](), [authentication](), [authorization](), [cli](), [oauth](), [oauth-2-0](), [rust](), [tokens](), [tutorial]() ### AI overview A tutorial showing how to build a Rust CLI that uses Auth0's OAuth 2.0 Device Authorization Flow, then create an Axum API that validates the resulting access token before allowing access to a protected route. ### Source excerpt Secure your Rust CLI applications with Auth0 Device Code flow and protect your Axum backend endpoints by validating JWTs with Rust's type safety. ## What invalid\_grant actually means, provider by provider DevFeed: [What invalid\_grant actually means, provider by provider]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-27T00:00:00Z Content type: article Language: en Sources: [WorkOS]() Topics: [OAuth 2.0](), [Authentication](), [Google](), [Microsoft](), [Slack]() Tags: [authentication](), [bug](), [oauth](), [oauth-2-0]() ### AI overview This article explains that OAuth 2.0's invalid_grant error covers five specification conditions, while providers use the same error differently. It compares provider-specific meanings for Google, Microsoft, Salesforce, Xero, QuickBooks, and Slack, and explains why recovery depends on provider-specific error details, often with a fallback to full re-authorization. ### Source excerpt One string, five spec conditions, and a different meaning at every provider. Here is what Google, Microsoft, Salesforce, Xero, QuickBooks, and Slack each mean by it. ## Add Cross App Access to Your OIDC Resource Application DevFeed: [Add Cross App Access to Your OIDC Resource Application]() Original publisher: [Read original article]() Author: Sohail Pathan Published: 2026-08-24T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OpenID connect (OIDC)](), [API](), [Authorization](), [JSON Web Tokens](), [Single sign-on (SSO)](), [OAuth 2.0]() Tags: [api](), [authorization](), [cross-app-access](), [jwt](), [oauth-2-0](), [oidc](), [okta](), [scopes](), [sso](), [token](), [xaa]() ### AI overview This guide explains how OIDC-federated applications can support Cross App Access (XAA) for API access on behalf of users. It covers validating and redeeming the ID-JAG, resolving users from claims, issuing access tokens, updating authorization server metadata, and testing the end-to-end flow. ### Source excerpt If you currently federate enterprise customers using OpenID Connect (OIDC) and want to allow applications to access your API on behalf of those users, this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was designed with OIDC in mind. Your authorization server already trusts the customer's IdP for single sign-on (SSO), and XAA reuses that same trust for API access. This guide details what you need to support, how to validate the grant, and how to resolve the user at your resource authorization server. Table of Contents How XAA in OIDC works Analyzing the ID-JAG claims XAA implementation checklist for OIDC-federated applications Mapping user identity from iss and sub Validating the ID-JAG and resolving the user Issuing the access token Updating authorization server metadata Making cross-application requests from your OIDC app securely Configure your XAA OIDC Resource app in Okta Create the OIDC requesting app for testing Create the OIDC resource app in Okta Register and configure the AI Agent in Okta Verify your Okta XAA setup on xaa.dev Configure OIDC SSO Verify the refresh token exchange for an ID-JAG token Redeem the ID-JAG for an access token at the resource authorization server Call the resource API with the access token Prove the XAA connection end-to-end Takeaways for implementors who also have SAML apps Learn more about Cross App Access, OIDC, and OAuth 2.0 How XAA in OIDC works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the customer's Identity Provider (IdP) for your authorization server. Your resource server accepts the token, identifies the user, and issues your own access token, all while leaving the customer's existing OIDC integration untouched. The sequence diagram shown below describes the OIDC XAA flow. Notice that the OIDC SSO flow stays the ## Add Cross App Access to Your OIDC Requesting Application DevFeed: [Add Cross App Access to Your OIDC Requesting Application]() Original publisher: [Read original article]() Author: Sohail Pathan Published: 2026-08-21T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OpenID connect (OIDC)](), [OAuth](), [OAuth 2.0](), [JSON Web Tokens](), [API](), [Authorization](), [AI Agent]() Tags: [agent](), [api](), [authorization](), [callback](), [claude](), [cross-app-access](), [identity](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [sso](), [third-party-applications](), [token](), [xaa]() ### AI overview This guide explains how an OIDC-federated application can use Cross App Access (XAA) to request resources from a third-party application. It describes exchanging a refresh token for an Identity Assertion Authorization Grant, exchanging that short-lived JWT for an OAuth access token, and using the access token for the resource API request. ### Source excerpt If you currently federate enterprise customers using OpenID Connect (OIDC) and want to connect with third-party applications, this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was designed with OIDC in mind. Your app already holds an ID token after sign-in, but it's the refresh token from that same sign-in that you exchange to reach a third-party app. This guide details what you need to support and how to make resource requests to a third-party app using XAA. Table of Contents How XAA in OIDC works XAA implementation checklist for OIDC-federated applications Request the ID-JAG token Request the access token Call the resource API Handle token expiration Making cross-application requests from your OIDC app securely Configure your XAA OIDC requesting app in Okta Register the requesting app in Okta Register the test resource app in Okta Register your requesting app at xaa.dev Register and configure the AI Agent in Okta Validate the XAA connection end-to-end Learn more about Cross App Access, OIDC, and OAuth 2.0 How XAA in OIDC works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app's user. You exchange the ID-JAG token for an access token to the resource application you're connecting with. The sequence diagram below describes the OIDC XAA flow and how your application fits into it. You'll handle the flow in two parts: where your application requests the ID-JAG from the IdP using the refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app's authorization server. XAA implementation checklist for OIDC-federated applications Follow the guide in this section to support XAA in your OIDC application when your app connects to a third-party resource application. The XAA flow places t ## RFC 9470 explained: The OAuth step-up authentication challenge protocol DevFeed: [RFC 9470 explained: The OAuth step-up authentication challenge protocol]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS]() Topics: [OAuth 2.0](), [Protocol (disambiguation)](), [API](), [Authentication](), [Authorization](), [OpenID connect (OIDC)](), [client]() Tags: [api](), [authentication](), [authorization](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [protocol]() ### AI overview This article explains RFC 9470, the OAuth 2.0 Step-Up Authentication Challenge Protocol. It describes how a resource server can tell a client that the current access token does not meet the required authentication level and how the client can obtain stronger authentication, including the roles of acr_values, max_age, and auth_time. ### Source excerpt How an API tells a client that the user needs to authenticate again, why acr_values is only a request while max_age is a requirement, and what the auth_time claim actually proves. ## Scaling Autonomous Operations with AWS DevOps Agent and ServiceNow DevFeed: [Scaling Autonomous Operations with AWS DevOps Agent and ServiceNow]() Original publisher: [Read original article]() Author: Jack Hwang Published: 2026-08-06T19:55:26Z Content type: tutorial Language: en Sources: [AWS DevOps & Developer Productivity Blog]() Topics: [Amazon Web Services](), [DevOps](), [incident](), [Model Context Protocol](), [Incident response](), [AI Agent](), [Access Control](), [OAuth 2.0](), [observability]() Tags: [access-control](), [ai-agent](), [ai-ml](), [artificial-intelligence](), [automated-incident-response](), [automation](), [aws](), [devops](), [generative-ai](), [incident](), [mcp](), [oauth-2-0](), [observability](), [technical-how-to]() ### AI overview This tutorial explains how to integrate AWS DevOps Agent with ServiceNow through the Model Context Protocol and ServiceNow Action Fabric. The workflow connects AWS incident investigation with governed ServiceNow actions, using OAuth 2.0, tool discovery, access controls, and automated root cause analysis. ### Source excerpt This post is co-written with Govind Menon, Head of MCP Product at ServiceNow. Introduction Enterprise teams managing applications on AWS often rely on ServiceNow as their IT service management (ITSM) system for incident tracking, change management, and configuration management. When incidents occur, engineers must context-switch between AWS, third party observability tools and ServiceNow, manually correlating [...] ## Announcing OAuth Device Authorization for the Appwrite CLI: Log in from your browser DevFeed: [Announcing OAuth Device Authorization for the Appwrite CLI: Log in from your browser]() Original publisher: [Read original article]() Author: Chirag Aggarwal Published: 2026-07-29T00:00:00Z Content type: release Language: en Sources: [Appwrite Blog]() Topics: [Appwrite](), [OAuth](), [OAuth 2.0](), [Command-line interface](), [Authentication](), [Authorization](), [browser]() Tags: [announcements](), [authentication](), [authorization](), [browser](), [cli](), [oauth](), [oauth-2-0](), [sign-in](), [trust]() ### AI overview Appwrite announces OAuth Device Authorization for the Appwrite CLI. The CLI opens or provides a browser URL where users confirm a device code, review requested permissions, and authorize sign-in using their existing browser session instead of entering a password in the terminal. ### Source excerpt The Appwrite CLI now signs you in through your browser. Confirm a device code, review permissions, and authorize, without typing credentials into your terminal. ## Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls DevFeed: [Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls]() Original publisher: [Read original article]() Author: Akanksha Bhasin Published: 2026-07-28T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [Flask](), [OpenID connect (OIDC)](), [Tutorial](), [API](), [Authentication](), [Authorization](), [OAuth 2.0](), [Python](), [Web app]() Tags: [api](), [authentication](), [authorization](), [flask](), [oauth](), [oauth-2-0](), [oidc](), [pkce](), [python](), [security](), [tutorial](), [web-app]() ### AI overview This tutorial explains how to build a Flask dashboard that uses Okta OpenID Connect for user sign-in and OAuth 2.0 access tokens to call a protected backend API. It also covers PKCE, custom scopes, self-service registration, and validating scopes to control API responses. ### Source excerpt Python syntax and the flexibility of the Flask microframework make it a popular choice for quickly building web applications. While Flask provides the essentials to get you started, you'll need to tackle two critical pieces yourself: secure user authentication and authorization for your backend services. After all, how do you securely sign users into your application? And once they're signed in, how does your app fetch data from a backend service that only serves authorized requests? This tutorial shows you how to solve both. You'll build a Flask dashboard app that signs users in with Okta using OpenID Connect (OIDC). Once signed in, the app uses the resulting OAuth 2.0 access token to call a separate backend API that responds only to authorized requests. In this common pattern, a web app needs to fetch data from a protected backend service. You'll use Authlib, an OIDC client library, to configure the Authorization Code flow with Proof Key for Code Exchange (PKCE) automatically. You'll also learn how to add a custom scope to the access token and validate it on the backend to control what data the API returns. Check out the complete source code on GitHub and get started without setting it up from scratch. Table of Contents Build a Flask app with OIDC authentication Create an app integration in the Okta Admin Console Enable self-service user registration Add secure user login to a Flask application with Okta Create a basic Flask web application Configure Flask environment variables Implement the OIDC authentication logic Run the Flask OAuth web app Call a protected API with OAuth scoped tokens Build a protected users API Extend the Flask app to interact with the resource server Update the Flask UI to display protected data Test the protected API integration Learn more about OAuth and OIDC Build a Flask app with OIDC authentication In this tutorial, you'll build a simple dashboard application and learn how to: Securely sign users in to view their profile information us ## Enable Your SAML Requesting App for Cross App Access DevFeed: [Enable Your SAML Requesting App for Cross App Access]() Original publisher: [Read original article]() Author: Alisa Duncan Published: 2026-07-17T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OAuth 2.0](), [Authorization](), [JSON Web Tokens](), [OpenID connect (OIDC)](), [API](), [AI Agent]() Tags: [api](), [authorization](), [claude](), [cross-app-access](), [digital-signature](), [identity](), [idp](), [implementation](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [payload](), [saml](), [signing](), [sso](), [xaa]() ### AI overview This guide explains how SAML-federated applications can use Cross App Access (XAA) to connect to third-party applications without migrating to OpenID Connect. It covers exchanging a SAML assertion for an OAuth refresh token, an ID-JAG, and an access token, along with token validation and Okta configuration. ### Source excerpt If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to connect with third-party applications without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to make resource requests to a third-party app using XAA. Table of Contents How XAA in SAML works XAA implementation checklist for SAML-federated applications Request the refresh token Request the ID-JAG token Request the access token Handle token expiration Making cross-application requests from your SAML app securely Configure your XAA SAML Requesting App in Okta Register and configure the AI Agent in Okta Test the SAML 2.0 app Validate the XAA connection end-to-end Learn more about Cross App Access, SAML, and OAuth 2.0 How XAA in SAML works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app's user. You exchange the ID-JAG token for an access token to the resource application you're connecting with. The sequence diagram shown below describes the SAML XAA flow and how your application fits in. You'll handle the flow in two parts: where your application requests the ID-JAG from the IdP using a refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app's authorization server. XAA implementation checklist for SAML-federated applications Follow the guide in this section to support XAA in your SAML application when your app connects to a third-party resource application. The XAA flow places the burden of token validation onto the IdP and the resource ap ## Keycloak 26.7.0 released DevFeed: [Keycloak 26.7.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-07-09T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [API](), [Authentication](), [Authorization](), [Security](), [OAuth 2.0](), [saml]() Tags: [api](), [authentication](), [authorization](), [deprecated](), [haproxy](), [high-availability](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [persistence](), [provisioning](), [release](), [saml](), [security](), [sso](), [traefik]() ### AI overview Keycloak 26.7.0 introduces preview support for SCIM-based user provisioning and simplified multi-cluster high availability, along with enhanced HAProxy and Traefik reverse-proxy guidance and step-up authentication for SAML clients. The release also adds a more secure, OAuth 2.0-compliant Identity Brokering API v2, while V1 remains enabled by default but is deprecated. OID4VCI improvements remain experimental. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities for users and administrators of Keycloak. The highlights of this release are: Automate user provisioning with the SCIM API (preview) Simplified multi-cluster high availability without external caches (preview) Enhanced reverse proxy guides with blueprints for HAProxy and Traefik Step-up authentication for SAML clients Read on to learn more about each new feature. If you are upgrading from a previous release, also review the changes listed in the upgrading guide. Security and Standards Stronger security for the Identity Brokering API The Identity Brokering API allows applications to retrieve tokens obtained from external identity providers during federated login. Version 2 of this API replaces the legacy V1 with a more secure and standards-compliant design: Client-level authorization -- access to external tokens is controlled per client using dedicated settings (Allow retrieve external tokens and an identity provider allow list) instead of assigning broker roles to individual users. Confidential clients only -- public clients are rejected, ensuring that only authenticated clients can retrieve external tokens. OAuth 2.0 compliant -- the endpoint uses POST and returns standard JSON responses with access_token, error, and error_description fields. Session-based token storage -- a new Store token in session option keeps tokens in the user session for faster access, with automatic cleanup on session expiry. Database storage remains available for persistence across sessions. V2 is now supported but disabled by default. V1 is deprecated but still enabled by default for backward compatibility. In a future release, V1 will be removed and V2 will become the default. For more information, see the Identity Brokering APIs chapter in the Server Developer Guide. Progress on Verifiable Credentials (OID4VCI) (experimental) Verifiable Credentials (OID4VCI) allow organizations to issue tampe ## /.well-known/oauth-authorization-server DevFeed: [/.well-known/oauth-authorization-server]() Original publisher: [Read original article]() Author: Joost de Valk Published: 2026-07-08T00:00:00Z Content type: tutorial Language: en Sources: [The Website Specification]() Topics: [OAuth 2.0](), [OAuth](), [OpenID connect (OIDC)](), [Authorization]() Tags: [authentication](), [authorization](), [discovery](), [jq](), [json](), [jwks](), [oauth](), [oauth-2-0](), [oauth2](), [oidc](), [openid](), [openid-connect](), [optional](), [rfc](), [scopes](), [server](), [servers](), [signing](), [well-known]() ### AI overview Explains the OAuth 2.0 authorization server metadata document defined by RFC 8414, how it differs from OpenID Connect Discovery, and when servers should publish it. It covers required endpoints, URL construction for path-based issuers, implementation details, common mistakes, and a curl and jq verification example. ### Source excerpt A JSON metadata document describing a plain OAuth 2.0 authorisation server's endpoints and capabilities. The non-OIDC sibling of openid-configuration; only needed if you run an authorisation server. ## Device Code Phishing Exploits OAuth Authorization to Steal Authenticated Sessions DevFeed: [Device Code Phishing Exploits OAuth Authorization to Steal Authenticated Sessions]() Original publisher: [Read original article]() Author: Lindsey O'Donnell-Welch Published: 2026-06-22T13:00:00Z Content type: article Language: en Sources: [Huntress Blog]() Topics: [Cybercrime](), [Security](), [OAuth](), [OAuth 2.0](), [Microsoft Teams](), [Authorization](), [sessions]() Tags: [credentials](), [cybercrime](), [device-code-phishing](), [microsoft-teams](), [oauth](), [oauth-2-0](), [phishing](), [security](), [sessions]() ### AI overview Huntress researchers explain how device code phishing abuses OAuth and device authorization flows to steal authenticated sessions. The article describes its use in Microsoft Teams lures and phishing-as-a-service offerings, and explains why the technique is difficult for defenders to address. ### Source excerpt During the June Tradecraft Tuesday, Huntress researchers looked at device code phishing variations and why threat actors love this attack so much. [Next page]()