Proposal for more flexible implementation

[merijndejonge]

Hi,

I have a suggestion for making oidc-token-manager (otm) more flexible such that it can be used in more situations. The motivation for this is that the implementation of otm currently does not work (for security reasons) in a chrome extension. I don't know but similar problems may exist on other platforms.

The issue I encountered is that it turns out that the communication from a popup window to its opener window (using window.opener) does not work in the chrome extension. There is a good (security) reason for this as is discussed at https://code.google.com/p/chromium/issues/detail?id=92669. Fortunately, chrome provides an identity api that works nicely in chrome extensions, but it is pretty low-level compared to otm and oidc-client.

While looking for a solution, I discovered that google has a (simple) api for oath2.0 authentication (https://developer.chrome.com/apps/app_identity). This api is working perfectly in a chrome extension.

Thinking more about the implementation of otm I came to the realization that it actually combines the following three sets of functionality:

• managing the authentication flow. Actually, the library supports a couple of flows: the popup flow, the silent refresh flow, and an in-place flow. These flows are demonstrated in the sample by popup.html, frame.html, and index.html, respectively. (I don't know yet what modal.html is for...).
• Managing oidc. The library is using oidc-client to take care of this.
• Managing tokens. In particular storing and loading of tokens.
• Triggering actions (such as silent refresh) when certain events (e.g., token expiration) eccur.

In my opinion, oidc-client is a nice concise library doing a very good thing in creating proper query url's maning meta data from the authority, etc. On the other hand, otm can be improved by factoring out different parts and making these parameters of the class. Essentially, what otm should do is managing tokens, that is:

• initiation an auth flow whenever necessary,
• controlling the storage of tokens in a token store,
• triggering actions on particular events (such as when a token expires)

To show what I mean, I have created a new implementation of the token manager (see attachment) consisting of the following parts:

• Token class. This is exact the same code as is part of oidc-token-manager, but I've factored it out into a separate file.
• TokenStore. This class contains functionality for storage of tokens. It is pretty much similar to the original otm code, but slightly simplified and factored out in a separate class.
• AuthFlowController. This class contains the knowledge about how an authentication flow should be. It consists of three atomic actions: getTokenAsync, renewTokenAsync, and logoutAsync. The class is parameterized with an oidcClient and an authentication flow. The latter implements a particular flow.
• AuthFlowWebsitePopup. This class implements the flow for a popup in an ordinary html site. This is similar to the popup example in the original otm source code.
• AuthFlowChrome. This class defines the flow for an chrome extension. It makes use of the chrome.identity API.
• TokenManager. This class combines the oidcClient, AuthFlowController, and token store. It defines the functions getTokenAsync, renewTokenAsync, and logoutAsync. It does not yet support automatic renewing of tokens. Nor does it trigger actions on certain events. This can easily be added later.

I've also included a demo that shows how it works.

I think this leads to a simple and clear implementation that is more flexible usable. Because the AuthFlowController is parameterized with the authentication flow, there is no longer a need to differentiate this in the config file. This means there is no longer a need for the property "popup_redirect_uri". Furthermore, I simplified the popup handling such that it can also be used for the silent redirect. Consequently, there is no longer a need for a frame.html (as was the case in the demo app).

Currently, I did not yet implement an in-place authentication flow because I don't need it. This should be not difficult to implement though. At some points I might have over simplified things a bit, which may require some additional thoughts.

I'm very much looking forward to your reaction. Hopefully you like it and we can further improve it into a v2.0 of oidc-token-manager.

Regards, Merijn

Latest code (as of 2016-01-20)

• 2016-01-20 sample.zip

Initial code

• sample.zip

[brockallen]

Thanks for the feedback. I'm always happy to improve on it. My main problem right now is time... when I get some more time I can look more into this. Thanks.

[brockallen]

Also, BTW, if we were to do this refactoring, I'd want this to be involved: https://github.com/IdentityModel/oidc-client/issues/2

[merijndejonge]

Yes, me too! I didn't have time for it now, but that should definitely be done!

On Tue, Jan 19, 2016 at 2:17 PM, Brock Allen notifications@github.com wrote:

Also, BTW, if we were to do this refactoring, I'd want this to be involved: IdentityModel/oidc-client#2 https://github.com/IdentityModel/oidc-client/issues/2

— Reply to this email directly or view it on GitHub https://github.com/IdentityModel/oidc-token-manager/issues/38#issuecomment-172849625 .

[brockallen]

Closing, as this has been addressed in the updated oidc-client (https://github.com/IdentityModel/oidc-client-js) replacement.

[merijndejonge]

Hi Brock,

I'm currently investigating the current implementation of oidc-client to see if it supports my scenario (oauth authentication in a google chrome extension). I think I should use the popup methods of your library. Do you have an example somewhere that explains how to get this to work? Do you know anyone who has succeeded in using your library in a browser extension? Thanks for your help!

Kind regards, Merijn de Jonge

On Wed, May 25, 2016 at 2:08 PM, Brock Allen notifications@github.com wrote:

Closing, as this has been addressed in the updated oidc-client ( https://github.com/IdentityModel/oidc-client-js) replacement.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/IdentityModel/oidc-token-manager/issues/38#issuecomment-221553973

[brockallen]

No sorry, I don't. There is cordova support and an example (both contributed), but I'm not sure how close that would be to your situation.

[bobekhj]

@merijndejonge Hello, have you ever got a solutions for this? I am working on the same scenario now and researching available options. Any help would be appreciated. Thank you

[brockallen]

This repo is retired. use https://github.com/IdentityModel/oidc-client-js/ instead.

[merijndejonge]

Although the repo is retired I would like to answer the question of @bobekhj :-)

I've struggled a lot on getting oidc to work in a chrome extension. For a long time I used the solution I proposed in this thread, but eventually I had difficulties in keeping it in sync with the oidc code. Moreover, my approach was using a chrome api which at that time was not available in Firefox and Edge. For firefox that has been fixed now. I'm not sure about Edge.

Using the oidc with a popup window was really causing trouble in the context of an extension as you may have encountered. It simply doesn't work well across all browsers that support web extensions. You may find several threads where I'm addressing this (e.g., https://github.com/IdentityModel/oidc-token-manager/issues/34, and https://github.com/IdentityModel/oidc-client-js/issues/248), but there are also some threads for firefox (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1292701).

Eventually, I decided that authentication using a popup for executing the authentication flow simply doesn't work well for chrome extensions (at least at that time). I therefore decided to use the (less secure) password grant type. Since that time I'm no longer using oidc client. With this grant type it was fairly easy to get authentication work. It also works in all browsers that support web extensions.

BTW, for normal singe paged applications, I'm triggering the authentication flow from the MVC application that hosts web application. This was explained very will by Ben Cull (see https://youtu.be/3rtq8M1s95c). I based a collection of template projects from this video in which I applied his approach to the default VS 2017 project templates for Angular and AspNetCore. See https://github.com/bjcull/OidcTemplate.

[bobekhj]

@merijndejonge thank you so much for your reply. I think Chrome's API supports authentication flows using launchWebAuthFlow API as described here: https://developer.chrome.com/apps/app_identity You can register your plugin's return URL and you should be redirected back to the site you were on. I haven't tried yet, but I think, next week I'll start writing this. I'll get back to you on the results.