Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add WWW-Authenticate Header on 401 #119

Closed
JohnCMcDonough opened this issue Sep 18, 2018 · 8 comments
Closed

Add WWW-Authenticate Header on 401 #119

JohnCMcDonough opened this issue Sep 18, 2018 · 8 comments
Labels
feat New feature or request.
Milestone

Comments

@JohnCMcDonough
Copy link

Is there any way we can add the WWW-Authenticate header to a 401 response so that a user using a web browser will be prompted for credentials?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

@aeneasr
Copy link
Member

aeneasr commented Sep 18, 2018

WWW-Authenticate only works for HTTP Basic Authorization, it doesn't make sense with the flows currently supported by Oathkeeper. Also, most clients will be programmatic ones (API) and not browsers accessing HTML websites.

@JohnCMcDonough
Copy link
Author

We’re allowing client credentials to be provided using Basic auth for some of our simpler clients and web services.

@aeneasr
Copy link
Member

aeneasr commented Sep 18, 2018

I see, maybe we could add a configuration setting to enable this for the client_credentials authorizer to enable this. Whalt do you think?

@JohnCMcDonough
Copy link
Author

That sounds good!

@aeneasr
Copy link
Member

aeneasr commented Sep 19, 2018

Perfect then, feel free to create a PR!

@JohnCMcDonough
Copy link
Author

I've never written anything in Go, but I'll give it a shot!

@aeneasr aeneasr added the feat New feature or request. label Sep 23, 2018
@aeneasr aeneasr added this to the unplanned milestone Sep 23, 2018
@ngrigoriev
Copy link
Contributor

I actually have a better idea. Currently there is a mutator that adds the headers. This mutator is applied only in case of a positive response. I would probably create two mutators instead - one for positive response and one for negative. And I would extend the list of values available for the template to include some request-specific ones (host, path, maybe original request headers etc). This would cover a bunch of additional use cases without breaking the concept of being the authorizer for APIs.

@aeneasr
Copy link
Member

aeneasr commented Sep 16, 2019

That's a good idea! We wanted to have a "deny" strategy but we were not completely sure how to approcha this. Maybe splitting mutators into allow/deny is the way to go!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

No branches or pull requests

3 participants