Skip to content
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.

Thinktecture.IdentityModel.Oidc project #50

Closed
mciureanu opened this issue Apr 16, 2014 · 14 comments
Closed

Thinktecture.IdentityModel.Oidc project #50

mciureanu opened this issue Apr 16, 2014 · 14 comments

Comments

@mciureanu
Copy link

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
Copy link
Member

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
Copy link
Contributor

ciaranj commented May 12, 2014

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
Copy link
Member

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

@ciaranj
Copy link
Contributor

ciaranj commented May 12, 2014

@leastprivilege
Copy link
Member

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
Copy link
Contributor

ciaranj commented May 12, 2014

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

@ciaranj
Copy link
Contributor

ciaranj commented May 14, 2014

.... 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
Copy link
Member

see here:
#54

@ciaranj
Copy link
Contributor

ciaranj commented May 15, 2014

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
Copy link
Member

Implicit just means that the client authentication is implicit.

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

@ciaranj
Copy link
Contributor

ciaranj commented May 15, 2014

(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
Copy link
Member

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
Copy link
Contributor

ciaranj commented May 15, 2014

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
Copy link
Member

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants