Authorise null to access your pod

[crspybits]

On a sign in, I'm seeing this: https://github.com/crspybits/SolidAuthSwift/blob/main/Docs/README/AuthorizeNull.png

@wrmack looked and says this comes from appUrl.origin. https://github.com/crspybits/SolidAuthSwift/issues/1

Is there a reason it isn't coming from client_name in the registration request?

Thanks!

[jeff-zucker]

I'm no expert but I believe this message from NSS comes from the origin, not the registration request bBecause that is how trustedApp status currently works on NSS - it looks for the origin of the app and compares it to the trustedApp list. It is apps coming from the origin that you are giving permission to. At some point in the future the use of origin will probably be something like verifiable WebIDs for apps, but until that process is in place, trust of apps (as distinct from users) is based on the browser's announced app origin.

Apps coming from the command line do not send an origin so the login flow for command line apps is different than for browser apps. I'm not familiar with SolidAuthSwift, so I have no idea how it manages to have a browser with a null origin.

[crspybits]

Hey, thanks for the quick response. SolidAuthSwift is a client-side library, that we are developing, intended for use with native iOS mobile apps. Internally, it uses a ASWebAuthenticationSession to do web browser redirection. From those docs In iOS, the browser is a secure, embedded web view.. I did a little looking at origin but I can't say as I really understand it yet or how I could supply it in this context. Not sure how apps using our library could come to be on a trustedApp list either.

[jeff-zucker]

@crspybits - I know zero about iOS and not much about the registration process but I'll take a shot at answering and see if it helps. One way to solve it is to wrap your app in a localhost webserver so that contact between your apps come from http://localhost:2000 or whatever. Then that becomes the app's origin, the browser will send it along with all requests and as long as http://localhost:2000 is listed as a trustedApp, things should work. The other alternative is to operate as if you are outside a browser which bypasses the trustedApp issue since out-of-browser apps are expected to have null origin. To do that, you'd need to get a JWT token in a browser then manually pass that token with each fetch request. Inrupt's generate-oidc-token is an app that gets a JWT by starting in the console, hopping to the web, and then the token is spit back to the console. Users can copy and save the JWT and then use it to login. The app then logs in with it and bypasses the trustedApp registration process. If you use NSS only, you can also login with username/password and bypass the token retrieval process. I have all of this working in my Solid-Node-Client library which documents the JWT and username/password methods.

If the above doesn't make sense or you run into problems, the expert on the topic is Inrup'ts @NSeydoux .

[wrmack]

Did a bit more prodding. ASWebAuthenticationSession inherits directly from NSObject (the root object) so there is no access to any sophisticated network methods (such as setting the http header origin). ASWebAuthenticationSession itself simply takes the request url, a redirect url and a callback completion handler. It is not possible to pass it any other info. When the login page is called there does not appear to be any origin sent through http headers. There are no request headers at all. (login.pdf). There are other iOS APIs that allow setting http headers such as https://developer.apple.com/documentation/authenticationservices/asauthorizationproviderextensionauthorizationrequest But that is a special use case for enterprises. There is discussion on the web about setting origin using the webkit API. I would prefer to stick with the recommended secure option. We might have to park that issue for now.

[crspybits]

Thanks, @wrmack for this additional prodding :).