OIDC Implementation for InAcademia

The InAcademia service uses the OpenID Connect standard to provide validation of an end-users affiliation with an academic institution. In this protocol the InAcademia service acts as an OpenID Connect provider (OP), and to validate an affiliation your service acts as a Relying party (RP).

This document is NOT a complete implementation reference of an OIDC RP for InAcademia. To ensure that the full benefits of the OpenID Connect standard and the InAcademia service are realised, it is strongly recommended that merchants use an OIDC client that has passed the OIDC certification (as listed here: https://openid.net/certification/ in the section “Certified Relying Parties”). This document assumes you are using an existing RP or RP library and provides suggestions on how to configure your client in general terms for use with InAcademia.

Examples of configuration for specific clients can be found here: https://inacademia.org/client-rp-examples/

In ‘Transaction: validate affiliation’ the protocol flow and the messages exchanged in one transaction are described. All supported operations are described more in-depth in Supported operations.

Terminology and legend

In addition to the terminology defined by OpenID Connect standard, here follows some clarifications and additional terms used in this document.

Term Clarification
Relying Party (RP) Part of your service acting as a client of the InAcademia service using the OpenID Connect protocol.
OpenID Provider (OP) The InAcademia service.
Institution The academic institution the end-user is affiliated with.
Transaction One validation of affiliation at the InAcademia service. A transaction starts when the InAcademia service receives a valid OpenID Connect authentication request, and ends when the response of the validation is returned via the redirect URI.
Formatting Description
text literal values
<text> value substitution

Transaction: validate affiliation

To validate an end-users affiliation with an institution you must be registered with the InAcademia service and have a valid client id at the OP, see Registration Your Service.

Start of transaction: Authentication Request

A transaction is initiated when an Authentication request is received at the OP. The authentication request is sent by redirecting the end-user to:

<inacademia_base>/InAcademia/authorization?nonce=<nonce>&state=<state>&redirect_uri=<redirect_uri>&response_type=id_token&client_id=<client_id>&scope=<scope>

InAcademia endpoints:

Discovery endpoint: https://op.srv.inacademia.org/.well-known/openid-configuration

Authorization Endpoint: https://op.srv.inacademia.org/InAcademia/authorization

OIDCProvider Issuer: https://op.srv.inacademia.org

All parameters are described in Authentication request. Documentation of the authentication request can be found in the section of the specs about Authentication using the Implicit Flow.

Note: Because of the redirect, the request is made by a client (typically a web-browser), and the response is delivered in the fragment identifier of the given redirect URI (see below).

End of transaction: Redirect URI

If the transaction succeeds, an ID Token (encoded as a JWT) will be returned in the fragment identifier part of the redirect URI. This can then be parsed using some scripting language in the browser (e.g. Javascript) running in the browser at the redirect URI.

Documentation of the response to a successful authentication can be found in the specs section on Successful authentication request.

Registration with the InAcademia service

Please see https://inacademia.org/registering-your-service/

Supported operations

OpenID Provider Configuration

To get the provider configuration of the InAcademia provider, the RP should make the following request:

GET /.well-known/openid-configuration HTTP/1.1
Host: <inacademia_base>

The response will be a JSON document containing, for example, the authorization endpoint (where to direct the authorization request to validate the end-users affiliation).

Full documentation of the provider configuration exchange can be found in OpenID Connect Discovery.

Affiliation validation

Authentication request

The authentication should be directed to:

<inacademia_base>/authorization

The following parameters are allowed in the authentication request (any others will just be ignored):

Parameter name Value/description State
response_type id_token Required
client_id <client_id> Required
scope See Scope Mapping table below Required
redirect_uri URL to send response to, must be previously registered with the InAcademia service Required
nonce opaque string to associate the client sessions with the issued ID Token Required
state opaque string to maintain state between your RP and the InAcademia OP; the state value is returned to the merchant RP in the case of any error scenario. A unique value per user session is advised. Recommended
claims Any additional claims that should be returned in the id token Optional
aarc_idp_hint URL-encoded entityID to indicate which is the Home Organization of an end user with the intent to skip the discovery service. Introduced in Q2-2022. Optional
idp_hint opaque string to indicate which is the Home Organization of an end user with the intent to skip the discovery service. Deprecated spring/summer 2022. Optional
Table: Parameters

 

Supported Scopes

The type of affiliation validation for the transaction is specified in the scope of the authentication request. There are two categories of scopes allowed:

  • Affiliation: what type of affiliation should be validated?
  • Identifier: what type of identifier is requested (persistent, to be able to identify returning users subsequent to the first validation, provided that the relevant attributes are supported and released by the institution, or transient, unique for each validation transaction)?

A valid scope string must fulfill the following:

  • Exactly one value from the affiliation category of scopes must be specified.
  • At most one value from the identifier category may be specified. If no value from the identifier category is specified, transient (see below table for description) is assumed.

Hence, the affiliation scope is required while both identifier and other scopes are optional. Any ambiguous scope strings will be immediately rejected by the InAcademia service (refer to the Possible Errors Section below).

The table below contains all values, grouped by category, allowed in the scope string:

  Scope Description
Affiliation student Is the end-user a student at the institution?
  faculty+staff Is the end-user a teacher/researcher (faculty) or a worker (other than teacher/researcher, staff) at the institution?
  employee Is the end-user an employee at the institution?
  member This person is either a student, faculty, staff or employee at the institution
Identifier persistent Unique identifier, persistent for this end-user subsequent to the first validation, provided that the relevant attributes are supported and released by the institution, and where the validity of the identifier depends on the institution maintaining its persistence.
  transient Transient identifier, which is unique for each transaction.
Table: Scope Mapping

 

Additional claims

To request additional claims about the end user, the claims parameter can be specified in the authentication request, see Claims Parameter in Authentication request. Only “id_token” is supported as a top-level member and requests.

The additional claims that can be requested can be seen in the following table:

Claim Value Description
country (deprecated) Not required (empty) The country of the users home institution
domain (deprecated) Not required (empty) The domain name of the users home institution
idp_hint (to be deprecated) Json object in the following format: "idp_hint": {"value": "852a417caadd2225496b583962c432ec8b84212e"}

Value is an opaque string to indicate which is the Home Organization of an end user

Deprecated spring/summer 2022.

re-use detection A list of unique identifiers (an opaque string)

Intends to detect abuse of one-time offers

Table: Additional Claims

 

Identity Provider Hinting

IdP_hinting is an extension to the InAcademia service that intends to assist merchants who are keen to reduce the number of clicks a student needs to make in validating a sale or registration process, and can also be used in offering services to use cases in specified countries.

An RP registered with the InAcademia service can indicate a link between its own ‘discovery service’ and the institution by including an IdP Hint in the Authorization request to InAcademia. This will result in InAcademia redirecting the user to its Home Organization directly instead of prompting them to select an institution from a Discovery Service UI. This has the added benefit of allowing merchants to create lists of uniquely referenced IdPs available on a country-by-country basis, and/or to target specific institutions or subsets of institutions with specific campaigns.

IdP hinting is based on the list of academic institutions as published by eduGAIN, and also includes entities only available nationally where InAcademia is registered in that national federation. When IdP hinting is used, it will trigger InAcademia to directly route a user to the selected institution, without the need for the user to arrive at a discovery service.

Institutions will sometimes change the technical infrastructure InAcademia relies on to validate a user, e.g. with a new version of their software, or when the name of the institution changes. In such cases the IdP hint information needs to be updated as well. While these changes are not frequent on a per institution level, it is still recommended to automatically refresh the list a merchant used on a nightly basis.

The IdP Hint Assertion feature helps merchants verify that the validation returns from the institution used to initiate the validation.

There are two ways that RPs can indicate they know the Home Organization of the end user:

  • aarc_idp_hint request parameter, as introduced at v3.3.0 (suggested).

Note that prior to v3.3.0 the idp_hint parameter was supported, that required the hint to be formatted as a sha1 hash. The idp_hint and sha1 hash-based approach is no longer supported for new customers of InAcademia.

For example:

`<inacademia_base>/InAcademia/authorization?nonce=<nonce>&state=<state>&redirect_uri=<redirect_uri>&response_type=id_token&client_id=<client_id>&scope=<scope>&aarc_idp_hint=<aarc_idp_hint>`
  • idp_hint claim (deprecated at v3.3.0).

For example:

 `<inacademia_base>/InAcademia/authorization?nonce=<nonce>&state=<state>&redirect_uri=<redirect_uri>&response_type=id_token&client_id=<client_id>&scope=<scope>&claims={"id_token"}:{"idp_hint":{"value":"3b4ef690b63e7ea4ba3d0576a928d38b49daa326"}}}`

InAcademia provides and maintains a mapping between aarc_idp_hint values and Display Names of Home Organizations that is available here. This data is provided for the purposes of merchants consuming the JSON-format data to create a list of the institutions at which InAcademia can be utilised from which users can select. It will be necessary for merchants to either dynamically consume and update the list or monitor the data in order to incorporate any updates into the merchant service. If the data is not monitored or utilised to support live updates to the selectable institutions, the request will contain a stale hint.

As at InAcademia v3.2.0, in the case the IdP hint fails, InAcademia will fall back to a discovery service where the user is requested to manually select its home institution from a global list. However, merchants must be aware that at this point a user could select an alternative IdP, rather than the IdP that the merchant has offered the discount to.

InAcademia v3.3.0 (for release Q2-2022) will return the user to the merchant redirect_uri in the event that an invalid or stale hint is received.

Transaction success

If the transaction succeeds an id token and the state (if included in the initial authentication request) will be returned in the fragment identifier part of the redirect URI (see Successful authentication request). The id token is a JSON Web Token, containing a JSON document with all returned claims, see the table below. The id token should be inspected and validated, see ID Token Validation.

Claim Description
aud list which must contain your client id, otherwise the id token must be rejected
auth_time when the end-user authenticated at its institution
exp the id token’s expiration date, approximately 30 minutes after the end-user authenticated at its institution
iat when the id token was issued
iss issuer identifier of the InAcademia service, must exactly match <inacademia_base>
nonce if your initial authentication request contained a nonce, this value should be matched exactly with that
sub identifier of the transaction/end-user. If a transient identifier was requested this value will be unique per transaction. If a persistent identifier was requested this value will be unique per end-user valid subsequent to the first validation, provided that the relevant attributes are supported and released by the institution, and where the validity of the identifier depends on the institution maintaining its persistence.
requested_scopes a json object containing all the scopes that the RP originally requested in the authentication request. The client MUST verify that the scopes contained in requested_scopes are exactly the same with the ones originally requested, otherwise the id token must be rejected. An example of requested scopes in the id token is as follows : "requested_scopes": {"values": ["openid","persistent","student"]}
Table: The ID_token

 

id token claims

The id token may also contain additional claims. The claims in the table Additional (optional) id token claims below will be included if:

  • you are allowed to obtain them
  • they were requested in the initial authentication request (see Additional Claims section above)
  • the institution provides them to the InAcademia service
Claim Description
country country code (ISO_3166-1_alpha-3) of the institution
domain domain name of the institution
idp_hint Json object in the following format: "idp_hint": {"value": "852a417caadd2225496b583962c432ec8b84212e"} (deprecated at spring/summer 2022)
reuse_detection A list of unique identifiers (an opaque string)

Table: Additional (optional) ID token claims

Where the RP requests the idp_hint claim, the validation response will assert that the user has been validated as an affiliate of the specific institution that was the subject of the request (feature name ‘IdP Hint Assertion’. To receive an assertion of the requested idp_hint, the relying party (the merchant) should include the claim ‘idp_hint’ in its authentication request, this example also specifies the requested idp_hint in claims:

| OIDCAuthRequestParams claims={“id_token”:{“idp_hint”:{“value”:”https://your.requested.idp/saml”}}} |

The hint that was subject of the claim will be validated, and then returned inside the id_token if there is a match. Where the idp_hint claim does not match the IdP used on the response from the IdP, no IdP_hint will be included in the id_token.

For those merchants that choose to utilise this feature, it adds a further level of validation and can mitigate against exploitation by other users or third parties, ensuring that the user subject to the validation is not only affiliated with academia, but is affiliated with a specific institution.

The IdP Hint Assertion feature will be offered as default from v3.3.0, and will be initiated by the GET parameter; it will not be necessary to include idp_hint as a claim from v3.3.0.

Transaction fail

A transaction will only be started if:

  1. the RP is registered with the InAcademia service and has a valid client id
  2. the Redirect URI, specified in the authentication request, is among the URL’s given when registering with the InAcademia service
  3. the authentication request contains the valid client id
  4. the scope specified in the authentication request is valid
  5. the response type is support and valid (only id_token is supported)
  6. the claim specified is supported
  7. the entityID can be resolved

If 1. or 2. is not satisfied, no response will be sent to the RP, instead an error will be displayed to the end user. If 3. to 7.. are not satisfied, an error response will be sent to the RP (see Possible errors table below for error codes). The error response will be encoded in the fragment part of the redirect URI:

<redirect_uri>#error=<error_code>&error_description=<error_description>

where the error_description is optional and therefore might be missing.

The transaction will fail if:

  • the end-user wants to validate its affiliation with an unknown institution (for the InAcademia service) or an institution not part of eduGAIN
  • the end-user was not authenticated at the selected institution
  • the institution did not provide enough information to the InAcademia service to validate the affiliation
  • the end-user did not give consent to release the necessary information

If the transaction fails an error code, and where practicable an error description, will be returned in the fragment part of the redirect URI (in the same way as described above).

Possible errors

Error code Reasons
access_denied end-user unauthorized, unknown or non-eduGAIN institution, the affiliation could not be validated, user denied consent
invalid_scope invalid scope specified in the authentication request
invalid_request invalid, mismatching or missing redirect_URI, invalid response_type or unsupported response_type in the authorisation request
unauthorised_client invalid or missing client_id in the authentication request

See ‘InAcademia Functional Flow With Errors’ for more detailed information concerning the possible error flows. It is strongly recommended that the client is configured to manage all scenarios.

Skip to content