When integrating towards to OIDC platform you will need to provide a redirect_uri where you will receive the Authorization Code/Token. Traditionally this This is done by specifying an endpoint in the backend of your web application. By default  Using the JS Connector do with its default redirect mode does not need any special considerations on the backend, but when using method inline or window, you can integrate further with the JS Connector. See the following sections for further information on Back-end implementation of the JS Connector:

...

Implementing redirect_uri

...

Since the JS Connector can open an iframe or a window for you, the handling of the post-authentication step is also important. This section will explain how you can take advantage of cross-domain messaging (XDM) to send the received code / tokens from the active window or iframe to the parent page (your site).

The redirect_uri needs to handle the authorization response in order to receive authorization code and tokens on behalf of the user. This information is either delivered as part of the URL, or as a FORM POST depending on which response_mode is specified in the parameters.

Then, if you follow the callback page example for redirect_uri, you will see that special XDM calls are made to pass the information from the window/iframe to the listening JS Connector instance on the main site.

Finally this will cause the callback function passed in the doConnect method to be called with the data retrieved in the authentication response

With specific token_url and/or userinfo_url (experimental feature)

You can have the JS Connector call token_url and userinfo_url endpoints with the received data from the authentication response.

Token endpoint (token_url)

...

JSON

{

    access_token: "654fe6f11ad61ceb1697d643b5fc59", 

    token_type: "Bearer", 

    expires_in: 3600, 

    scope: "openid phone address", 

    id_token: "...."  // JWT

}

...

Userinfo endpoint (userinfo_url)

Using the access token (which also could be stored on the server) to access user information OIDC.

...

JSON

{
 "sub": "9578-6000-4-127698",
 "iss": "https://oidc-preprod.bankidapis.no/auth/realms/preprod",

"iat": 1485866449,

...

when using code flow or hybrid flow

The implicit flow is special since it contains both the id_token and the access_token directly the requests to the redirect_uri, thus making back-end handling trivial. With the code flow and hybrid flow the back-end becomes slightly more complex since the Token endpoint must be called from the back-end to retrieve a complete set of tokens. It is beyond the scope of the JS Connector to describe how the response from the Token endpoint is further handled across the back-end and front-end of the merchant site.

Implementing redirect_uri when using Value Added Services

When using a Value Added Service, eg. TINFO Userinfo, with the JS Connector, the back-end implementation must also handle the request for such services based on an access_token that is delivered to the back-end along with the id_token, either directly in the request to the redirect_uri for implicit_mode or indirectly via an intermediate exchange with the Token Endpoint for code flow and hybrid flow. It is beyond the scope of the JS Connector to describe how the response from any Value Added Service is further handled across the back-end and front-end of the merchant site.

Implementing redirect_uri when using method window or inline

When the JS Connector is used with method inline or window, you can provide it with a callback function that will be executed after the Authorization session has completed. In addition, the JS Connector will close any popup window or clear the iframe contents.

Here is how:

• After handling authorization response on your redirect_uri page, return a JS snippet that will issue a postMessage() call (in a special format) to the parent window.
• The JS Connector will listen for this message and execute the callback given to OIDC.doConnect({ ... }) and close any windows/clear iframes.

See  callback page example for redirect_uri,

See also more information on cross-domain messaging (XDM).

Problem with cross-domain messaging from popup window on Internet Explorer / Edge browsers

If you use Window mode and cross-domain messaging on the redirect_uri page to the JS Connector, then Internet Explorer may block the communication between the window and the parent. This can happen when the window being opened is on a different domain than the parent site. To work around this problem, you need to setup an endpoint on your domain as the doInit oauth_url parameter. This way the window is opened on your own domain first and cross domain messaging should work.