Hi Donald, No, not all OAuth authorization code requests result in 3xx redirects. See Section 4.1.2.1: https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1
If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. That is the 4xx behaviour that you're describing. Yours, Emelia > On 8 Aug 2026, at 00:15, [email protected] wrote: > > Warren, > > Thanks for your quick reply. > > What Section of RFC 6749 allows a 401 status code response for an > Authorization Request? I am confused by the response being correct, since > all OAuth Authorization Requests are 302/303 Redirect responses. > > Best regards, > Don > Donald F. Coffin > Founder/CTO > > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > > From: Warren Parad <[email protected]> > Sent: Friday, August 7, 2026 3:32 PM > To: [email protected] > Cc: Emelia S. <[email protected]>; [email protected]; Jeremy J. Roberts > <[email protected]> > Subject: Re: [OAUTH-WG] How to properly implement Section 4.1.2.1 > Authorization Error Response for OAuth 2.x > > To be clear, regarding the your questions: > >> Does the IBM Verify Authorization Server properly implement Section 4.1.2.1. >> Authorization Error Response per the OAuth standard. > > Yes. > >> Are you stating these are valid OAuth 2.0 Authorization Flow responses when >> an OpenID Connect server should be acting like an OAuth 2.0 server without >> OpenID Connect capability? > > No, these are valid OAuth 2.0 Authorization Flow responses. > >> Is there a hierarchical relationship between OpenID Connect and the IETF RFC >> 6749 OAuth 2.0 standard? > > No, there is no relationship. > > > > > On Fri, Aug 7, 2026 at 9:13 PM <[email protected] > <mailto:[email protected]>> wrote: >> Good afternoon, Emilia and Warren. >> >> Thanks for your quick responses. >> >> Please clarify which table of results you reference: the first table >> (expected response) or the second table (IBM Verify responses). If the >> second table, are you stating these are valid OAuth 2.0 Authorization Flow >> responses when an OpenID Connect server should be acting like an OAuth 2.0 >> server without OpenID Connect capability? Can an OpenID Connect server >> support both OpenID Connect Authentication and perform OAuth 2.0 >> Authorization? >> >> The issue is that we test for compliance with the NAESB ESPI standard, not >> the OpenID Connect standard, which the ESPI standard does not support. >> Therefore, the GBA Certification Platform expects the Authorization Server >> to support the OAuth Authorization Flow requirements. Since I am not >> familiar with the OpenID Connect specification, is an OpenID Connect >> solution capable of supporting an OAuth Authorization Flow? >> >> Is there a hierarchical relationship between OpenID Connect and the IETF RFC >> 6749 OAuth 2.0 standard? According to IBM, the OpenID Connect specification >> supersedes the IETF RFC 6749 OAuth 2.0 standard and should therefore the >> OAuth 2.0 implementation should support the OpenID Connect Authorization >> Flow specification. In reviewing the OpenID Connect specification, the >> Authorization Flow section states that for an OpenID Connect Hybrid Flow, >> the Authorization Flow should follow the OAuth 2.0 standard. Does this >> indicate there is no hierarchical relationship between the OpenID Connect >> and OAuth 2.0 standards? >> >> Best regards, >> Don >> Donald F. Coffin >> Founder/CTO >> >> REMI Networks >> 2335 Dunwoody Crossing Suite E >> Dunwoody, GA 30338-8221 >> >> From: Emelia S. <[email protected] <mailto:[email protected]>> >> Sent: Thursday, August 6, 2026 1:23 PM >> To: [email protected] <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]>; Jeremy J. Roberts >> <[email protected] <mailto:[email protected]>> >> Subject: Re: [OAUTH-WG] How to properly implement Section 4.1.2.1 >> Authorization Error Response for OAuth 2.x >> >> Hi Donald, >> >> Looking at the table of results and test cases, for 1, 3 and 4, these are >> the correct responses per the results table, as otherwise the authorization >> server would be an open redirector. For test case 0, the response_type is >> required, so yes, redirecting back with the error of either invalid_request, >> or unsupported_response_type if it's present but unsupported, would be >> correct. For test case 5, redirecting back with invalid_scope would be >> correct, provided the client and redirect URI match. >> >> Do be careful not to mixup response_type (OAuth, OIDC) and response_mode >> (from OIDC), response_mode can often be inferred from response_type (e.g., >> code response_type often defaults to query as a response_mode). >> >> Hope that helps. >> >> Yours, >> Emelia >> >> >>> On 6 Aug 2026, at 18:30, [email protected] >>> <mailto:[email protected]> wrote: >>> >>> I am the Technical Manager of the Green Button Alliance. I am responsible >>> for certifying that electric, natural gas, and water utilities comply with >>> the North American Energy Standards (NAESB) Energy Service Provider >>> Interface (ESPI) standard and need a ruling from the IETF OAuth WG >>> regarding an issue that has arisen for Hydro One Networks, Inc. >>> >>> Hydro One Networks, Inc., the largest electric utility in Ontario, Canada, >>> implemented the NAESB ESPI (a.k.a. Green Button) standard in 2023, which >>> uses the OAuth 2.0 standard for customers to authorize client applications >>> to access their energy data. At the time, they were using an IBM Tivoli >>> Authorization Server, which fully complied with the Green Button Alliance >>> legislatively mandated certification test for Section 4.1.2.1. >>> Authorization Error Response. They recently upgraded to the IBM Verify >>> Authorization Server, which no longer passes the same Section 4.1.2.1. >>> Authorization Error Response tests. IBM has agreed to comply with the IETF >>> OAuth Working Group’s response to my questions. >>> >>> The GBA Certification test platform currently submits the following invalid >>> Authorization Endpoint requests and expects the Authorization Server to >>> comply with Section 4.1.2.1. Authorization Error Response error messages: >>> >>> iTestID >>> Label >>> Test Name >>> Query string >>> Status Code >>> Expected Error Message >>> 0 >>> Case 0: no response_type >>> Malformed Authorization Code Request (No response_type field-value) >>> ?client_id=(client_id)&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> 302/303 >>> ?error=invalid_request parameter and no or empty location header >>> 1 >>> Case 1: no client_id >>> Malformed Authorization Code Request (No client_id field-value) >>> ?response_type=code&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> 302/303 >>> ?error=invalid_request parameter and no or empty location header >>> 2 >>> Case 2: invalid response_type >>> Malformed Authorization Code Request (Invalid response_type field-value: >>> ?response_type=badresponsetype& >>> client_id=(client_id)&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> 302/303 >>> ?error=unsupported_response_type parameter and no or empty location header >>> 3 >>> Case 3: invalid client_id >>> Malformed Authorization Code Request (Invalid client_id field-value) >>> ?response_type=code& >>> client_id=invalid_third_party&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> 302/303 >>> ?error=unauthorized_client parameter and no or empty location header >>> 4 >>> Case 4: invalid redirect_uri >>> Malformed Authorization Code Request (Invalid redirect_uri field-value) >>> ?response_type=code& >>> client_id=(client_id)&redirect_uri=https://services.greenbuttondata.org&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> >>> <https://services.greenbuttondata.org&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018/> >>> >>> 302/303 >>> ?error=invalid_request parameter and no or empty location header >>> 5 >>> Case 5: invalid scope >>> Malformed Authorization Code Request (Invalid scope field-value) >>> ?response_type=code& >>> client_id=(client_id)&redirect_uri=(redirect_uri)&scope=FB=????&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>> 302/303 >>> ?error=invalid_scope parameter and no or empty location header >>> >>> All scope string values are application variable contents shown as () >>> entries if present. Malformed values are shown as strings. I do not test >>> for missing state= elements, although the NAESB ESPI standard requires them. >>> >>> The following table contains the current response by the IBM Verify >>> Authorization Server for each of the above test cases: >>> >>> >>> iTestID >>> Status Code >>> Response >>> 0 >>> 303 >>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallBack?error=unsupported_response_type&error_description=... >>> 1 >>> 401 >>> The response included a full-screen HTML showing the error “CSIAQ0154E The >>> requested OAuth 2.0 Client does not exist” >>> 2 >>> 303 >>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallBack?error=unsupported_response_type&error_description... >>> 3 >>> 401 >>> The response included a full-screen HTML showing the error “CSIAQ0154E The >>> requested OAuth 2.0 Client does not exist” >>> 4 >>> 400 >>> The response included a full-screen HTML showing the error “CSIAQ0167E The >>> redirection URI provided in the request is either invalid or does not match >>> any of the OAuth 2.0 Client’s pre-registered redirect URLs” >>> 5 >>> 302 >>> https://...verify.ibm.com/idaas/mtfim/sps/idaas/login... >>> >>> Note: >>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallback >>> is the value of the redirect_uri for all but the negative redirect_uri >>> tests >>> >>> The IBM team indicated that case 5 (invalid scope): The OpenID Connect spec >>> allows ignoring unknown scopes vs. returning an invalid_scope error >>> (https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). The >>> referenced section of the OpenID Connect standard is the Authentication >>> section, which is NOT what case 5 is testing. However, Section 3.1.2.2. >>> Authentication Request Validation of the OpenID Connect specification >>> indicates the Authorization Server MUST validate all the OAuth 2.0 >>> parameters according to the OAuth 2.0 specification. That includes (2) >>> verifying that a scope parameter is present and contains the openid scope >>> value (If no openid scope value is present, the request may still be a >>> valid OAuth 2.0 request but is not an OpenID Connect request). >>> The IBM team indicated that case 4 (invalid redirect): An OpenID Connect >>> certification has precedence over the IETF OAuth 2.0 RFC 6749 and >>> referenced their official OpenID Foundation cert test for invalid redirect >>> URI, which expects an error page, not a redirect >>> (https://www.certification.openid.net/log-detail.html?log=Lbzq5uCWSM1Sij3&public=true). >>> The NAESB ESPI standard does not support the OpenID Connect standard, so we >>> contend that the IBM Verify team’s position that their OpenID Connect >>> server does not need to comply with the IETF RFC 6749 and 6750 standards is >>> a “red herring”. For cases 0 and 2, they have demonstrated the ability to >>> support Section 4.1.2.4 Authorization Error Response properly. >>> >>> The business issue and why I am submitting this email is that Hydro One >>> Networks, Inc. is required by Ontario legislation to be certified by the >>> Green Button Alliance as being in compliance with the NAESB ESPI standard. >>> Without that certification, Hydro One Networks, Inc. will face continuing >>> financial penalties from the Ontario Energy Board. >>> >>> >>> Best regards, >>> Don >>> Donald F. Coffin >>> Founder/CTO >>> >>> REMI Networks >>> 2335 Dunwoody Crossing Suite E >>> Dunwoody, GA 30338-8221 >>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
