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

Support for direct access flow will be removed #34

Open
asergios opened this issue Aug 27, 2024 · 9 comments
Open

Support for direct access flow will be removed #34

asergios opened this issue Aug 27, 2024 · 9 comments
Labels
thetruthisouthere When the outside world breaks our inside world

Comments

@asergios
Copy link

Hey!

Ecoinvent will remove direct access flow support from their clients.
I believe this will make the interface stop working

"grant_type": "password",

I will be delaying this change on PROD for a bit so that alternatives can be discussed here.

Would you be open to implement Device Authorization Flow?
We are open to create a client for you to use this, I already have a proof of concept too.

I don't know what would be the best approach for you to save the client secret.

@asergios
Copy link
Author

asergios commented Sep 2, 2024

Flow would be something like:

curl --location --request POST 'https://sso.ecoinvent.org/realms/ecoinvent/protocol/openid-connect/auth/device' \  
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=<CLIENT_ID>' 

Response:
{"device_code":<DEVICE_CODE>,"verification_uri_complete":<VERIFICATION_URL>,"expires_in":600,"interval":5}

You temporarily save DEVICE_CODE and open VERIFICATION_URL on a browser for the user to allow access of your client to his resources.

Finally, you can get the access token with

 curl --location --request POST 'https://sso.ecoinvent.org/realms/ecoinvent/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'device_code=<DEVICE_CODE>' \
--data-urlencode 'client_id=<CLIENT_ID>' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:device_code'

I guess it doesn't make sense to use a confidential client here, but let me know what you think

@tngTUDOR tngTUDOR added the thetruthisouthere When the outside world breaks our inside world label Sep 27, 2024
@tngTUDOR tngTUDOR pinned this issue Sep 27, 2024
@tngTUDOR
Copy link
Contributor

tngTUDOR commented Sep 27, 2024

@asergios is this part:

You temporarily save DEVICE_CODE and open VERIFICATION_URL on a browser for the user to allow access of your client to his resources.

absolutely necessary ? [I mean the on a browser for the user to allow access ...]

@asergios
Copy link
Author

asergios commented Oct 7, 2024

@asergios is this part:

You temporarily save DEVICE_CODE and open VERIFICATION_URL on a browser for the user to allow access of your client to his resources.

absolutely necessary ? [I mean the on a browser for the user to allow access ...]

Hello @tngTUDOR, thanks for your answer and sorry for my late reply.
This is the plan yes. The intention is that the users types their credentials directly on the SSO.

@tngTUDOR
Copy link
Contributor

tngTUDOR commented Oct 8, 2024

ack @asergios .
so if I understand correctly, it will be impossible in the future to use the API without actual human intervention for the login phase ?

@asergios
Copy link
Author

asergios commented Oct 8, 2024

ack @asergios . so if I understand correctly, it will be impossible in the future to use the API without actual human intervention for the login phase ?

It won't be possible with the use of username/password. An API key should be the future alternative.
However, I think this auth flow fits activity browser better.

I am open to suggestions tho.

@tngTUDOR
Copy link
Contributor

tngTUDOR commented Oct 8, 2024

Speaking from a group of users that don't use activity browser too much, I have to say that the idea of an API Key is very very very compelling.
I definitely support the use of API Keys, which would definitely keep my work flows manageable (without a web browser)

@asergios
Copy link
Author

asergios commented Oct 9, 2024

I understand. I did not consider this, let me get back to you on this topic.
Meanwhile, we can keep this flow then. But I would still prefer for the ecoinvent_interface to use their own client instead of apollo-ui. That way I can disable direct flow on apollo-ui.

Wdyt?

jsvgoncalves added a commit that referenced this issue Oct 28, 2024
* As requested on #34, this sends a different client id to keycloak

#34 (comment)

Signed-off-by: João Gonçalves <[email protected]>
@tngTUDOR
Copy link
Contributor

@asergios I'm not sure we actually use the apollo-ui . My understanding of the code is that it only uses apollo-ui as client_id, but I might be wrong.
If that is the case, do you think it's necessary for the ecoinvent_interface to declare a different "client_id" ?

@tngTUDOR
Copy link
Contributor

tngTUDOR commented Oct 31, 2024

Here's my view of how could things be done, in a way that is useful for GUI and API users:

  • Users must use a compatible web browser to get an API_KEY from ecoinvent
  • ecoinvent_interface replaces the login+password flow, with an API_KEY kind of flow (with or without changing the actual client_id), using the API_KEY retrieved in the first step.

@asergios , if you already have an implemenatation that we could use for testing, we can make find some time to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
thetruthisouthere When the outside world breaks our inside world
Projects
None yet
Development

No branches or pull requests

2 participants