Thinktecture.IdentityModel.Oidc project

[mciureanu]

Hello.

1. I saw that this project is only used for the HttpModule. Personally I consider it would be great if this was the single project which a client or RP has to reference in order to integrate with an OpenID connect identity provider. I'm not sure about this, but it looks like there is not a lot of functionality used from Thinktecture.IdentityModel, (which could be duplicated here)

I'm speaking from the point of view of some developer of trying to convince some colleagues to use OpenID connect. A simple setup consisting in referencing a single dll would definitely mean an improvement.

1. Is there any particular reason why this client is not used in the other samples (which use directly OAuthClient)?
2. I would like if a the http module/open id connect client would support also a symmetric key type of signing. I'm almost sure that if I only mention the "x509" word, my "security proposition" would get ditched away. I'm not sure, but I believe I can implement this myself (extend the config section and ValidateIdentityToken method), but I wanted to ask for your opinion first. The server supports IdentityTokenSigningKeyType = SigningKeyTypes.ClientSecret after all (which by the way, doesn't work with "secret" as a client secret, but that's another issue...)

Thank you.

[leastprivilege]

These are all valid points for legacy applications. But since Microsoft already previewed their new OpenID Connect middleware for Katana - the module has currently no high priority. Feel free to work on it!

[ciaranj]

I would help on this, I need a ASP.Net/WebForms app to support OIDC so (I think) I cannot rely on the Katana middleware :(

[leastprivilege]

WebForms and Katana can work together (just like MVC and Katana).

[ciaranj]

sob I'm doing well today. I'd read: http://stackoverflow.com/questions/19423097/is-it-possible-to-use-katana-to-host-an-existing-webforms-application-within-a-w and trusted it :/

[leastprivilege]

Well - it is right and wrong - MVC and WebForms cannot be hosted using Katana. But you can still use Katana middleware (e.g. the templates in VS2013 use Google authentication middleware).

[ciaranj]

Ah, ok. right, thank you for the clarification, that makes sense :)

[ciaranj]

.... so I've investigated the katana OpenIdConnect middleware and it appears to not support the codeflow. I can't find any supporting documentation with it to suggest there is any intention to either (no raised issues, comments in discussion forums etc.) :( (this surprises me somewhat so perhaps I'm misunderstanding its purpose!)

Before I try and re-grok the source do you know for a fact that I'm wrong about this ? (also, and related it doesn't support the ability to get back an ID+Access token at the same time [ https://katanaproject.codeplex.com/discussions/542150 ] ) long story short, your module appears to be significantly better at first + second glance to my untrained eyes!

Update: Ah. https://katanaproject.codeplex.com/workitem/247

[leastprivilege]

see here:
#54

[ciaranj]

Thanks, that covers the access token, but I'm more concerned about them only supporting the implicit flow had loosely understood that flow as being the 'least secure' and should only be used when the client can't be trusted, but the implication of the middleware + azure is that implicit flows are A-Ok ?

[leastprivilege]

Implicit just means that the client authentication is implicit.

They also do hybrid flow btw - but IdSrv does not support that (yet).

[ciaranj]

(implicit) Sure, but doesn't that mean the level of trust you should be willing to grant requests from that client should be lower (for example issuing shorter duration access tokens?) (I had been planning to make sure all my internal (non mobile) trusted web applications utilised the code flow, based on this potentially wrong understanding!

[leastprivilege]

Well it depends on a number of factors - implicit is for JS/native applications (no client secret but redirect URI) where credential/consent should happen on the AS - whereas using code flow requires the flow triggered by a server and due to client credentials gives you additional features like refresh tokens.

[ciaranj]

Ok. That matches my understanding, I just (naively it would seem!) assumed that code flow was one of the commonest flows! Thank you as always!

[leastprivilege]

Closing this for now. Please open a new issue if you plan to work on an HttpModule for backwards compat.