COMING SOON! Introducing support for OAuth 2.0 Authorization Code Grant

This summer, the InAcademia team will deploy a new release that is dedicated to providing support for the OAuth 2.0 Authorization Code Grant*. I'd like to provide some additional information that should help you to understand the motivation for this change and the related timelines.

We believe that we are now at a point where the Authorisation Code Grant variation would offer more benefit to merchants utilising the InAcademia service than offered by the (now legacy) Implicit flow.

Is this a positive change? What are the benefits?

Primarily, this upgraded version would offer increased security as exemplified by this extract of information provided by the IETF on the topic:

   "The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code. Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client. The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner."

Ref: https://datatracker.ietf.org/doc/html/rfc6749#section-1.3

In contrast, while the ID Token provided under the Implicit flow is securely encrypted, a remote chance remains that users with sufficient expertise could manipulate the code, or the code could potentially be intercepted and successfully utilised if the RP does not thoroughly inspect the ID Token for the security features that were transported in its initial authentication request.

The Authorization Code flow with PKCE adds an additional step which allows us to protect the authorization code so that even if it is stolen during the redirect it will be useless by itself.

How would a merchant go about making the transition from Implicit Flow to Authorization Code Grant?

If the merchant is running a standard OIDC client or library, it should be possible to make a configuration change using standard options. The intended flow is simply specified in the authentication request towards InAcademia, using response_type "code" and the code expiry should be short-lived (no more than 5 minutes is recommended).

Example requests:

Implicit: /InAcademia/authorization?nonce=&state=&redirect_uri=&response_type=id_token&client_id=&scope=

Code: /InAcademia/authorization?nonce=&state=&redirect_uri=&response_type=code&client_id=&scope=

Code with PKCE: /InAcademia/authorization?nonce=&state=&redirect_uri=&response_type=code&code_challenge=&code_challenge_method=S256&client_id=&scope=

Response type, whether "code" or "id_token", has no impact on the scopes, claims or IdP Hinting features. This aspect of the structure of the id_token returned will stay the same as it is at v3.30. However, using the response_type "code", merchants will be able to request the claims in both the id_token or via userinfo endpoint. idp_hint or any other claims can now also be requested such that they are returned via userinfo endpoint as well as id_token. Using code_challenge=code challenge string in the authorization request initiates the PKCE flow. 

End users are unlikely to see any difference in the way that our services interact with one another.

It will still be necessary for the merchant to continue monitoring for replay attacks.

What is the timetable for making the change?

The following describes a proposal to implement the Authorization Grant Authorization Code Flow and to deprecate the Authorization Grant Implicit Flow.

It will be possible for merchants to adopt this change from the point of release of InAcademia/SVS v4.0.0, however, it is recommended that a period of robust testing is undertaken prior to launching any change to workflow in the merchant's environment.

Summary of proposed changes:

The InAcademia support team will be available to help throughout the introduction of this new flow.

Please do not hesitate to contact us with any questions or comments.

* The most recent specification for enabling third-party applications to obtain limited access to HTTP services is the OAuth 2.0 authorisation framework, that was approved by publication by the Internet Engineering Steering Group (IESG) under RFC 6749 https://datatracker.ietf.org/doc/html/rfc6749. Version 2.0 of the OAuth specification advised that the Authorisation Grant Implicit Flow variation (a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step) used by InAcademia, is deprecated. Furthermore , the OAuth 2.0 Security Best Current Practice document recommends against using the Implicit flow, due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.

Ref: https://oauth.net/2/grant-types/implicit/

Ref: https://www.oauth.com/oauth2-servers/server-side-apps/authorization-code/