Options for authentication in a mobile app

I’d like to let a user log in to a solid pod and stay logged in on a mobile app. The app can’t really use a popup.html so I’m wondering how to best do it.

I’ve seen that solid-cli has a way to get a cookie to send with future requests. Is that the best way to do it or are there alternatives, like perhaps a long life token of some sort?


Solid-auth-cli gives you persistent login and file access to both Solid pods and local files from the command line or a nodejs script and can be used with rdflib and other Solid libraries. It is a wrapper around solid-cli that provides the same interface as solid-auth-client. Let me know if you run into problems.


Hi jeffz - Thanks for your reply!

I looked at solid-cli and solid-auth-cli. They both work well on the command line but unfortunately are not easy to compile into React-Native (which lets you use JS libs but doesn’t give you a full nodejs environment so things like require(‘fs’) won’t work). I considered trying to strip out those bits to get it to work, but it somehow doesn’t seem like the right route to me now that I’ve seen that solid-cli does some clever magic and pretends to be a browser to log in via parsing html and suchlike.

I think I’m going to read about WebID auth and scratch my head about it for a bit longer. It’s not important for me to get this app working. It’s just a simple proof-of-concept sort of idea I’m playing with to learn a bit about Soild.


1 Like

Hi, @alexstacey Did you manage to implement this? If not try using custom chrome tabs. It lets you to login with your solid POD. But the tricky part is to handle the IDtoken and extracting the URI out of it which i find really difficult to implement at the moment.

It will be great if you have already found a solution for this.


Hi, No I tried a few things but didn’t get it working. Even if you log in with a browser window it becomes difficult to pass the cookie value back to the app because it’s set to http-only so you can’t read it with js.

It would be great if there was a better drop-in solution for authentication using just basic http requests that doesn’t need an html browser with cookie support. It’s limiting for anything that’s not a web site.

How are we going to make solid-enabled smart refrigerators?! :grin:

1 Like

@alexstacey Thanks for your reply. In this case i will try to set up a separate service and pass the data to it for now. Indeed it will be great to have a drop-in kind of solution. 0Auth 2 seems to be good but again handling the cookies seems to be tricky.

A similar issue of require(‘fs’) happened when I was trying Angular/Cordova… Now digging deeper…

Why not making a native app that connects to a web service that holds all Solid tools?

That’s an option. But require writing native versions of solid-auth-client and possible other libraries such as rdflib.js. Of course can think of it later.

Hi @jeffz, I feel one major barrier is the persistent storage of the OIDC session. The existing brower-based apps based on solid-auth-client are using Localstorage, which is not working in some mainstream mobile app hybrid frameworks (I personally tried Angular+Cordova and Ionic, also ReactiveNative as reported by @alexstacey ).

At the same time, I found solid-rest(also maintained by you) is designed to support other storage handlers, do you have any suggestion if developers want to manage the session information to the place they prefer?

Thanks very much

Solid-rest does not handle webId, it is for accessing things that are not Solid servers but which can be made to emulate Solid servers for purposes of storing and retrieving documents e.g. a local file system, a database, or an in-memory virtual file system, all of which can be accessed through rdflib and RDF methods. So Solid-Rest could be useful if what you want to do is create a Solid-like mobile environment that an app could address the same way it does a Solid server. But it is not useful for logging in to a Solid server.

I guess, I have a question for you - what storage do you have available in the programming environments you want to explore? how do you access it? (sorry, I don’t know much about mobile frameworks or apps)

If only the storage is the problem, this should be rather easy to change in solid-auth-client. Some methods accept a asyncStorage parameter which defines where it is stored (e.g. this method). I’m not sure if all necessary methods allow to set a different storage. If not, I guess a PR for that would be accepted and rather easy to do. You can also take a look at an old PR of me where I did this among other things (here).

Hi @jeffz, mobile apps don’t have localStorage. At least for iOS, it neither has anything like “file://” since it’s working in its own sandbox. Apps are only supposed to use restricted system APIs to persist local data or use databases such as SQLite or Realm.

@A_A, thanks for your tip! I’ve successfully used Cordova to bridge solid-auth-client.js and native logic with a customized AsyncStorage. Now I can fetch and persist some information through OIDC and possibly manipulate triples with native logic (if the following problem fixed.)

Now I come across the next problem:
After OIDC authorization, my mobile demo gets the object solid-auth-client without the “session” part. Other than that everything looks fine. Specifically,

  1. It contains “rpConfig” with almost all sub-fields (provider, defaults, store, registration, etc. ) similar to the web version.
  2. It also has requestHistory and oidc.session.privateKey.
  3. It has a field appHashFragment (which does not appear in web version) with empty value.

Do you have any suggestions? The redirect_uri has the scheme of ionic://, would that be the reason?

PS. sample Login/Authorization URIs initiated from ios app:



Sorry, I don’t have the time to help you much here. I’d try to narrow down where the error is happening, ie if it is inside solid-auth-client or inside oidc-rp. You could try to log everytime your storage is accessed, and also modify solid-auth-client to add additional logs there (or go into a debug mode if that’s possible in your setup).
If the error is inside solid-auth-client it’s likely easy to fix. If it’s inside oicd-rp I have no clue.