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

The auth header type should be taken from the openID Connect capabilities #543

Open
magopian opened this issue May 25, 2018 · 1 comment
Labels
enhancement stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.

Comments

@magopian
Copy link
Contributor

See #509 (review)

When authenticating using openID Connect, the headers that are sent to the kinto server are using Bearer, which is hardcoded. Instead it should use the header_type from the capabilities, eg:

  "openid":{
    "description":"OpenID connect support.",
    "url":"http://kinto.readthedocs.io/en/stable/api/1.x/authentication.html",
    "providers":[
      {
        "name":"google",
        "issuer":"https://accounts.google.com",
        "auth_path":"/openid/google/login",
        "client_id":"248628588820-707f9m6vs19jt7g41cev4iqkglu72u58.apps.googleusercontent.com",
        "header_type":"Bearer",
        "userinfo_endpoint":"https://www.googleapis.com/oauth2/v3/userinfo"
      }
    ]
  }

Fixing this might also fix the review from @leplatrem about the ugliness of splitting/concatenating strings to get the auth type and provider for openID Connect. If we can pass the full "provider capability" object, we'll be able to extract both the provider name and the header type.

@leplatrem
Copy link
Contributor

The PR #646 didn't entirely fixed this. It reads the token_type from the OpenID redirection payload but not from the server capabilites metadata.

But since we have a header_type setting on the server, we should use it.
https://kinto.readthedocs.io/en/stable/configuration/settings.html#openid-connect

@leplatrem leplatrem reopened this Oct 3, 2018
@alexcottner alexcottner added the stale For marking issues as stale. Labeled issues will be closed soon if label is not removed. label Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.
Projects
None yet
Development

No branches or pull requests

3 participants