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

PKCE and django client #216

Closed
rcludwick opened this issue Apr 7, 2020 · 3 comments
Closed

PKCE and django client #216

rcludwick opened this issue Apr 7, 2020 · 3 comments
Assignees
Labels

Comments

@rcludwick
Copy link

@rcludwick rcludwick commented Apr 7, 2020

Describe the bug

Using the django client:

Passing "code_challenge" to authorize_redirect() is ignored. A new code verifier and code challenge is created anyway.

But passing "code_verifier" to authorize_access_token() works as expected.

The end result is that for the tin foil hat types that are worried about random number generation, there's no way for the django client to create their own code_verfiers for PKCE.

Error Stacks

n/a

To Reproduce

A minimal example to reproduce the behavior:

django_client.authorize_redirect(url, code_challenge="some_code_challenge")
assert django_client.framework.get_session_data(request, 'code_challenge') == "some_code_challenge"

Expected behavior

The assert should pass

A clear and concise description of what you expected to happen.

The django client should not override "code_challenge" passed into kwargs.

Environment:

  • OS: Linux
  • Python Version: 3.7.3
  • Authlib Version: 0.14.1

Additional context

In BaseApp._create_oauth2_authorization_url(), my kwarg "code_challenge" is passed into kwargs.

But on line 170, a new code verifier is created. And then the ouath2 client create authorization url method() overwrites the code challenge that are still passed into kwargs.

@lepture
Copy link
Owner

@lepture lepture commented Apr 8, 2020

Can you check if it works in master code? I can' see any problem in master code.

@rcludwick
Copy link
Author

@rcludwick rcludwick commented Apr 9, 2020

I'll see if I can get to it this today or tomorrow. Biggest problem is that I have to recreate the issue on my personal development environment.

The work around for me is to just use the code verifier that gets created from the framework.get_session_data() call. But I can see people (like me) not necessarily trusting /dev/random, and wanting a stronger way of generating a secure code verifier.

@lepture lepture closed this as completed in 9a77e73 May 7, 2020
lepture added a commit that referenced this issue May 7, 2020
@lepture
Copy link
Owner

@lepture lepture commented May 7, 2020

@rcludwick fixed in the master code.

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

No branches or pull requests

2 participants