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

Secure the token #84

Open
fretchen opened this issue Aug 2, 2024 · 2 comments
Open

Secure the token #84

fretchen opened this issue Aug 2, 2024 · 2 comments
Milestone

Comments

@fretchen
Copy link
Collaborator

fretchen commented Aug 2, 2024

Is your feature request related to a problem? Please describe.
We are already working with a token. However, this has currently several shortcomings:

  • It is sent in clear text towards the backend for verification.
  • It cannot be reset.
  • There is no public key to verify it.
  • It is stored within the backend, so not really private.

Describe the solution you'd like
We should update the token to be a private key that is only known to the user and never sent to the backend. This could be done through a nicer cryptographic approach. Current idea:

  • create the token visible for the user.
  • store the associated public key with the appropiate storage_provider
  • use the private key to sign a simple message that shows that the token is valid, basically a very simple challenge.
  • this can be later also used for signing the job. So this will enable Let the job submission be signed sqooler#258
  • most likely this requires a new version for the API, but we will see.

Describe alternatives you've considered
We could also have tried to store a private key on the backend. However, this would not be private in any way and should be avoided.

Additional context

This is all part of an effort to establish cryptographic ownership of jobs as described here and enabling ideas like this on payment.

@fretchen fretchen added this to the v0.4.0 milestone Aug 2, 2024
@fretchen
Copy link
Collaborator Author

fretchen commented Aug 9, 2024

The approach with a private key is good for signing. However, it does not allow you easily to authentificate the user. Therefore, we might have further looks into this. For the moment it might be best to keep the API key for authentification very much like IBM is doing it as described here. Then we have a header which contains Authorization: Bearer YOUR_API_TOKEN_HERE. The full code example is:

import requests
 
reqUrl = "https://api.quantum-computing.ibm.com/runtime/jobs?limit=10&offset=0&exclude_params=true"
 
headersList = {
  "Accept": "application/json",
  "Authorization": "Bearer YOUR_API_TOKEN_HERE"
}
 
payload = ""
 
response = requests.request("GET", reqUrl, data=payload,  headers=headersList)
 
print(response.json())

@fretchen
Copy link
Collaborator Author

fretchen commented Aug 9, 2024

This could be nicely implemented through this API:

https://django-ninja.dev/guides/authentication/#global-authentication

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

When branches are created from issues, their pull requests are automatically linked.

1 participant