Build selenium integration tests

[brockallen]

That model the sample app.

[kristofdegrave]

@brockallen What do you want to do/test? I have some experience with selenium using protractor. If I can be of any assistance, let me know.

[cburgmer]

We have a working integration test that uses JSDOM and mocked XHR. We are currently discussing how much it's connected to the implementation of oidc-client-js itself (and therefor be difficult to change), but considering that the mocks are touching the interfaces governed by the OIDC specs it feels an acceptable outcome.

[brockallen]

@cburgmer so what are you suggesting? do you think you have a way to do end to end testing?

[cburgmer]

If by end-to-end you mean integrating with a real browser and a real OIDC provider, then no.

However because of the long timeout between token renewals I was looking for a way to mock the token renewal time.

What we now built on our side is a full orchestration of our OIDC flow inside the frontend by mocking out the integration points of oidc-client with the browser.

Taking ideas from https://github.com/IdentityModel/oidc-client-js/blob/release/samples/VanillaJS/oidc.js we are mocking the OIDC responses by providing access and identity tokens signed via a key pair just generated for the test. The flow is as follows:

0. Prerequisites: JSDOM as a real DOM replacement, window.location replaced with a trivial implementation to deactivate JSDOM's own loading mechanism.
1. Create a RSA key pair
2. Setup a mock response for the XHR (see e.g. fake-xml-http-request on npm) to /.well-known/openid-configuration and serve up authorization_endpoint, issuer, jwks_uri, check_session_iframe.
3. Setup a mock response for the XHR to the URL specified in jwks_uri of step 2 and serve up the JWK from the key pair generated in step 1.
4. Load oidc-client, and have it trigger the redirect to the IDP
5. Scoop the redirect URL from window.location and inspect client_id, redirect_uri, state, nonce.
6. Mock the IDP responding redirect URL with state, id_token, access_token and expires_in.
7. Trigger the callback mechanism of oidc-client with the URL from step 6.

You should be logged in successfully now.

Given a low value for the expires_in parameter of step 6 oidc-client should now start the renewal.

8. Wait for the iframe to appear in document.body and scoop up it's frame.src.
9. Use the parameters from that silent renewal similar to step 6 to build the mock URL of the IDP response.
10. Here's a bit of a hack: mock an iframe context, by overwriting window.parent and window.postMessage from JSDOM, so that the silent renewal of oidc-client picks up on the redirect from step 9.

A new token should now have been set.

Big help to finding this flow was reading code from oidc-client-js and jsdom, and activating the following

 import { Log } from 'oidc-client';
 Log.level = Log.DEBUG;
 Log.logger = console;

[brockallen]

Yea, seems like a lot of work. That's why for now I've just done manual testing with the samples.

[cburgmer]

The problem with Login though is that its failure usually has a big impact. Also your release process might not have room for a lot of manual testing (ours doesn't), so we felt we wanted to have some safeguard in place.
The above could possibly move into a standalone mock implementation if there's more parties interested in using it. Not sure if I would have time for maintaining this though.