search

fission-codes / auth-lobby

The authentication service that Fission services run.
https://auth.fission.codes
GNU Affero General Public License v3.0
12 stars 1 forks source link

Authentication in a native client #93

Closed Richienb closed 1 year ago

Richienb commented 2 years ago

OAuth allows native clients to authenticate users by hosting a local server and setting the callback url to be the localhost url. Then, the authentication service would provide the authentication details to the server in the url query parameters.

This used to be feature provided by the auth lobby but has since been phased out in favour of loading https://auth.fission.codes/exchange.html in an iframe and waiting for a message. In native applications, this is not possible since the service is not a website.

There is currently no supported way of getting authentication information to be passed directly to the native client. The current workaround is to use an older version of the API by setting sdk to v2 and extracting readKey and ucans from the query parameters:

https://github.com/fission-suite/auth-lobby/blob/7386ef78acb57eb31d94511574cf219b114e04c9/src/Application/Authorisation/State.elm#L136-L140

expede commented 2 years ago

Hmm yeah, we don't have anything for subsets of permission today. We do have account pairing (a special case of what you're trying to do) in the CLI today, which can communicate with browsers or other CLI instances. We use websocket-based channels to communicate between them (eventually IPFS pubsub 🤞), and bootstrap a secure channel. We designed that protocol to be able to extend to share more kinds of information over time, so it's very possible.

We're also going to need this when we support direct app-to-app auth 🤔

icidasset commented 1 year ago

We're in the process of extracting this functionality to Webnative. In Webnative v0.35 you can write your own implementation that doesn't use the iframe approach. See capabilities component in Webnative v0.35