IETF draft tightens OAuth token protections for native email clients
News
The IETF published revision 06 of OAuth Profile for Open Public Clients on September 17, 2026 UTC. The document cover says September 16, while the Datatracker records publication at 2026-09-17T02:26:53Z. This is an active Mail Maintenance working-group Internet-Draft with intended status Informational. It is not a final RFC, an approved standard, production guidance, a provider rollout, or a current requirement. No implementation or enforcement deadline has been announced. The revision 06 record and plain-text draft are the primary sources for the proposed behavior.
The revision matters because a successful OAuth login does not prove that every server receiving the resulting access token belongs to the same service. Revision 06 proposes explicit checks for every token destination and explains how clients using both HTTP and mail protocols should handle DPoP. The affected implementers are native-client developers, mail providers, and authorization-server operators supporting IMAP, POP, SMTP submission, or JMAP.
What changed in revision 06
Compared with the revision 05 text dated April 2, revision 06 adds two substantial pieces. New section 3.6 tells clients to verify where access tokens can be sent. New section 3.8 describes the limited way DPoP can coexist with non-HTTP protocols. The expanded security considerations explain counterfeit resource-server configurations and safer token storage.
Draft status controls every recommendation
The proposed MUST and SHOULD language applies within this draft profile. It does not impose a current obligation on deployed clients or servers. Teams should review and test the proposal, not treat it as an immediate production change order.
|
|
|
|---|---|---|
Token destination | No dedicated destination-validation section | Check every token destination |
DPoP | HTTP limitation noted | Separate HTTP and mail tokens |
Security analysis | General OAuth risks | Counterfeit servers and storage |
The main differences between revisions 05 and 06
Proposed OAuth flow checks a server destination before sending a token
Why checking the issuer is not enough
A counterfeit configuration can name a real OAuth issuer while directing the client to an attacker-controlled mail server. The user then sees a genuine authorization page and authenticates with the expected issuer. Those facts validate the login interaction, but they do not establish that the configured IMAP, POP, SMTP, or HTTP resource belongs to that issuer. Without a separate destination check, the client can present a usable access token to the wrong resource.
Issuer-only reasoning
The client confirms that the authorization response matches the expected issuer, then assumes the configured resource is safe. That assumption fails when configuration combines a genuine issuer with an unrelated resource server.
Revision 06 proposal
The client verifies each place where it might present the access token. The check covers configured resources and any HTTP host reached after a redirect.
When authorization-server metadata contains protected_resources, the proposed profile requires a matching entry for each destination. A complete advertised list takes precedence over the fallback rule. This lets a provider explicitly authorize cross-domain arrangements, such as an issuer on one registrable domain and mail hosts on another.
Illustrative authorization-server metadataJSON
{ "issuer": "https://auth.example.com", "protected_resources": [ "imap.example.com", "smtp.example.com", "https://api.example.com" ] }
If protected_resources is absent, revision 06 proposes a fallback that permits only hosts sharing the issuer's registrable domain, as determined with the Public Suffix List. IP literals and names without a registrable domain fail. This fallback supports simpler same-domain deployments, but it does not prove that every host under a shared domain is trusted. An untrusted host on that domain remains a limitation. Providers with split domains or complex hosting should therefore map and advertise their intended resources explicitly if they experiment with the draft.
Redirects are token destinations too
For HTTP resources, a safe starting URL is not enough. The draft proposes checking every redirected host before an access token is sent. A redirect must not become an unchecked route to another resource server.
DPoP still does not work through OAUTHBEARER
DPoP proofs are defined for HTTP. A proof binds to an HTTP method and URI and travels in an HTTP header. The existing OAUTHBEARER SASL mechanism has no field for that proof. Revision 06 therefore does not make DPoP-bound access tokens usable over IMAP, POP, or SMTP submission. Supporting sender-constrained access tokens in those protocols would require new protocol work and compatible server implementations.
HTTP resources
- Token type: A DPoP access token can protect JMAP or another HTTP resource.
- Proof transport: The client attaches the DPoP proof to the HTTP request.
Mail protocols
- Token type: A Bearer access token remains necessary for OAUTHBEARER.
- Proof transport: IMAP, POP, and SMTP cannot carry the DPoP proof today.
For a client that mixes JMAP or another HTTP resource with IMAP, POP, or SMTP, the draft describes separate token requests. HTTP resources can receive DPoP access tokens. Non-HTTP resources receive Bearer access tokens. A refresh token can still remain bound to the client's DPoP key, so possession of the refresh token alone is insufficient for refresh requests, even though a resulting mail-protocol access token is a bearer credential.
- Inspect token_type: Clients must use each returned token with the matching authentication scheme.
- Separate resources: HTTP and non-HTTP destinations require separate access-token requests in this model.
- Check compatibility: The authorization server must understand DPoP and resource indicators for the split to work.
- Fail safely: A DPoP token returned for a non-HTTP-only request signals incompatible behavior.
Other safeguards added to the proposed profile
Revision 06 also tightens the setup around discovery and credential use. These additions support the two main changes by reducing the chance that a client trusts unverified configuration or exposes credentials before it has authenticated the connection.
- Protocol discovery: A failed OAUTHBEARER response can direct a client toward authorization-server information.
- TLS first: Clients check TLS and the server certificate before sending credentials.
- Host attribute: The proposed profile requires the host value in the OAUTHBEARER exchange.
- HTTPS endpoints: OAuth metadata and related endpoints receive explicit HTTPS checks.
- Untrusted registration data: Authorization servers should not treat dynamic client metadata as verified identity.
The draft's native-client scope is now more explicit, but revision 06 did not invent native-only support. Earlier revisions already focused on native clients that need interoperable access to open protocols without a prearranged client-provider relationship. The changes refine that profile rather than extend it to every OAuth client type. The official revision history distinguishes this September update from the original working-group adoption.
What implementers should review now
The sensible response is an engineering review and lab test, not an unscheduled production migration. Teams can use the draft to expose assumptions in current designs while tracking later revisions that can change the details.
|
|
|
|---|---|---|
Client developers | Every token destination | Issuer match proves resource ownership |
Mail providers | Issuer and resource domains | Same-domain fallback covers split hosting |
Authorization operators | Metadata and token types | All clients support split tokens |
Security teams | TLS and token storage | Draft language is production policy |
Review focus by role
A practical review should inventory the configured IMAP, POP, SMTP submission, and JMAP endpoints for each issuer. Include hosts reached through HTTP redirects. Record which destinations share the issuer's registrable domain, which depend on cross-domain hosting, and which use IP literals or internal names that would fail the proposed fallback.
- Read the draft: Review sections 3.6, 3.8, and 4 with client and server owners.
- Map domains: Document issuers, resource hosts, redirects, and organizational trust boundaries.
- Trace token use: Identify every code path that can attach an access token to a request.
- Check existing controls: Confirm TLS validation and secure refresh-token storage before considering new logic.
- Test in a lab: Exercise cross-domain resources, redirects, token_type handling, and unsupported-server failures.
Do not deploy solely because of this draft
Internet-Drafts can change, be replaced, or expire. Production decisions need a provider-specific compatibility plan, test evidence, and review of the version current at implementation time.
Why this does not change DMARC
This work concerns client authorization and mailbox access. DMARC, SPF, and DKIM authenticate domains or messages in the mail-delivery path. Revision 06 requires no DNS authentication record change, does not repair a DMARC failure, and does not improve inbox placement by itself.
At Suped, we keep these workstreams separate. Suped's DMARC monitoring handles aggregate authentication reporting, source identification, and policy management. It cannot diagnose whether a native client sent an OAuth token to the wrong resource server. A domain health check can verify DNS-based authentication separately.
Likewise, an email tester can inspect a delivered message's authentication and content signals, but it does not test OAuth protected-resource metadata or DPoP compatibility. OAuth review belongs in client, provider, and authorization-server testing.
What teams should take away
Revision 06 addresses a specific trust gap: a real OAuth issuer can be paired with a resource server that should never receive the issuer's token. Its proposed answer is to validate every destination against protected_resources, with a registrable-domain fallback when that metadata is absent. The fallback intentionally rejects IP literals and hostnames without a registrable domain, but it cannot distinguish trusted and untrusted hosts sharing one domain.
The draft also documents a workable split for mixed clients without claiming that DPoP now operates over mail protocols. DPoP access tokens remain for HTTP resources. Bearer access tokens remain necessary for OAUTHBEARER on IMAP, POP, and SMTP. Implementers should study the change, map their endpoints, and test compatibility in a lab while the working group continues its work.
