Skip to content
This repository was archived by the owner on Dec 13, 2018. It is now read-only.

OpenIdConnectOptions API cleanup #478

Closed
Eilon opened this issue Sep 19, 2015 · 14 comments
Closed

OpenIdConnectOptions API cleanup #478

Eilon opened this issue Sep 19, 2015 · 14 comments
Assignees
Milestone

Comments

@Eilon
Copy link
Contributor

Eilon commented Sep 19, 2015

  • Rename AuthenticationMethod to RedirectBehavior
  • Investigate why DefaultToCurrentUriOnRedirect is needed at all
  • Remove HtmlEncoder property and use the service instead. Need to ensure that the service is registered when the OIDC services are registered.
@Eilon Eilon added this to the 1.0.0-rc1 milestone Sep 19, 2015
@kevinchalet
Copy link
Contributor

Remove HtmlEncoder property and use the service instead. Need to ensure that the service is registered when the OIDC services are registered.

FYI, this property was added with the POST authorization requests support. I opted for a specific property in the options to allow the developer to replace the global encoder - for instance, to support Russian chars in Razor 😄 - while still being able to use a custom one for the OIDC middleware, where you probably prefer applying a very strict encoding.


On a related note, we should strongly consider replacing ResponseType and ResponseMode's default values to use the authorization code flow with GET responses.

Indeed, the authorization code flow offers the most secure approach - since it doesn't imply disclosing the identity/access token to the user agent - and is universally supported.

@Eilon
Copy link
Contributor Author

Eilon commented Sep 19, 2015

Yeah we understood the place where the HtmlEncoder property is used, but felt that having a unique customization for it isn't necessary at this time. That options class has already, what, let's say, 500 different options on it? 😄 We figured removing a very unlikely extensibility scenario would be a good thing (for now). We felt it's far more common to replace it for the entire app.

Re: The OIDC properties, would like to hear from @Tratcher and @brentschmaltz regarding changing the defaults of those two properties.

@kevinchalet
Copy link
Contributor

Yeah we understood the place where the HtmlEncoder property is used, but felt that having a unique customization for it isn't necessary at this time. That options class has already, what, let's say, 500 different options on it? 😄 We figured removing a very unlikely extensibility scenario would be a good thing (for now). We felt it's far more common to replace it for the entire app.

Yeah, it needs a good diet 😄

@HaoK HaoK self-assigned this Sep 21, 2015
@HaoK HaoK removed their assignment Sep 21, 2015
@HaoK
Copy link
Member

HaoK commented Sep 21, 2015

Eww, no don't want to do this now :)

@brentschmaltz
Copy link
Contributor

@Eilon DefaultToCurrentUriOnRedirect was added automatically set the OIDC message.RedirectUri to the CurrentUri. This controls where the user-agent sends the post back.

HtmlEncoder was added for the reasons @PinpointTownes mentioned. Before removing, we should consider that IdentityProvider are independent, this is different that say, the CultureInfo for an application where each page will display that same Culture.

@leastprivilege
Copy link
Contributor

So can someone explain the purpose of DefaultToCurrentUriOnRedirect ?

@leastprivilege
Copy link
Contributor

I don't get that - the redirect_uri (as in the oauth or oidc protocol) or wreply (in ws-fed) is a fixed value. This is as fixed as the client_id.

What's the purpose of the new option? Also - do you handle deep links corectly now (like persisting them in a state protected cookie)?

@kevinchalet
Copy link
Contributor

DefaultToCurrentUriOnRedirect's purpose is to control whether the address of the current request will be used to determine the final location of the user agent if AuthenticationProperties.RedirectUri is null. Despite the name, it has nothing to do with the redirect_uri used when communicating with the OP.

That said, the OIDC middleware is the only one having such an option: the other middleware ALWAYS use the current URL as the fallback value when AuthenticationProperties.RedirectUri is null. This property is clearly pointless: #202 (comment)

@leastprivilege
Copy link
Contributor

OK - then I misunderstood that. Maybe because the naming is so confusing ;)

@kevinchalet
Copy link
Contributor

I guess renaming AuthenticationProperties.RedirectUri to AuthenticationProperties.ReturnUrl would help a bit 😄

@HaoK
Copy link
Member

HaoK commented Oct 15, 2015

@PinpointTownes File a new bug for the RedirectUri => ReturnUrl rename if you feel strongly about that. I'm not opposed :)

@HaoK
Copy link
Member

HaoK commented Oct 15, 2015

I'm nuking DefaultToCurrentUriOnRedirect as we just do this everywhere else without a flag

@HaoK
Copy link
Member

HaoK commented Oct 15, 2015

8359038

@HaoK HaoK closed this as completed Oct 15, 2015
@HaoK HaoK added 3 - Done and removed 2 - Working labels Oct 15, 2015
@DamianEdwards
Copy link
Member

This should've had a corresponding announcement issue created as it's a breaking change.

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

6 participants