Insecure URIs for client development

[tomkersten]

When running Connect in "production" mode, you are not allowed to register clients with an insecure HTTP scheme (ie: http). This tends to be a problem if you are developing a client and want your authentication process to interact with your local machine instead of a deployed application.

In other words, when I'm developing a client application, I'd like to be able to register a client with a redirect_uri of http://127.0.0.1:9000/callback (and/or localhost, I suppose). Outside of these two specific/reserved hostnames, I personally have no issue with the existing SSL requirement that is in place for client applications.

[christiansmith]

@tomkersten I'm guessing you're using the implicit flow, correct?

I looked further at the specs because I realized from looking at the code that something wasn't covered in our previous discussion.

When using this flow, the Redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http: scheme with localhost as the hostname.

http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest

Before proceeding with any changes to the logic, I'd like to better understand the reason for this restriction. It must be there to prevent some kind of vulnerability.

Is there any reason you can't run the server in "development" mode on your live server? It would just take a few tweaks to your Dockerfile, and copying your production.json to development.json if I'm not mistaken.

[tomkersten]

Implicit: yes.

I guess I wouldn't want the system to be running in "development" mode because I would want this behavior in "production" mode...

The wording in the spec seems to be pretty clear that this should not be supported. I'm unsure of where to go with this. Putting the entire Connect server in development mode "all the time" to support this seems flawed. Supporting the spec as written seems to be at odds with the desired behavior. Given the localhost mention (albeit, in the context of natve apps), I could see an exception being made...but...I'm not sure what to respond with, tbh.

[adalinesimonian]

Perhaps you can run a second instance of Anvil Connect with NODE_ENV set to development, and if necessary, have it connect to the same Redis database.

In my current environment, I have two instances of Anvil Connect; one is a production instance, and the other is for development. I create clients and test them against the development server, and then update the registration details when I need to move to production. Effectively, I have https://sso.example.com and https://sso-dev.example.com. Personally, I choose to keep them using different databases for complete isolation.

[tomkersten]

First, I want it to be clear I can do what @vsimonian suggests, and I'm ok with it. However, it does feel a bit odd to me, would not be my personal preference, and seems like a burden the typical developer would not want to take on just to be able to develop client applications. I am bringing this up mostly as a discussion point, as I wouldn't be surprised if it were to come up again with other users. Also, I appreciate the dedication to properly implementing according to the spec.

The reason I say others may be confused by this is that I assume mos devs, like me, will compare working with a Connect server as if it were Google, Github, or some other OAuth provider: I register applications (clients) to auth and get scopes inside my own "ecosystem." When I work with these systems, I am able to register local redirects over HTTP without issue. I have one place I go to register an application, not two.

I am not sure I understand how allowing, say, a host of 127.0.0.1 (with any port) could be considered a security issue, but, at the same time, I am not qualified to say it isn't. Therefore, if the final answer becomes "Will not implement because it violates the spec", I get it and will deploy 2 systems as you suggest.

This was something I ran into and had to dig into the Docker container to debug what was going on (error was not clear). After figuring it out, I found it confusing/odd relative to other systems.

[adalinesimonian]

I've sent an e-mail to one of the core co-authors of the OIDC spec asking for rationale behind the restriction. I'm hoping for a response. I have a hunch that it's to protect the tokens as they are sent back through the browser.

[adalinesimonian]

I've received a response which seems to confirm the interpretation that we all understand:

The reason for requiring TLS is the security issue. Since the tokens are largely barer, the whole security model relies on the channel protection. During the development phase, it would be ok for you to use a non-https endpoints, but on production, it is vital to have the endpoints protected by TLS as required in the specification.

[tomkersten]

Actually, I can interpret this in two conflicting ways.

During the development phase, it would be ok for you to use a non-https endpoints, but on production, it is vital to have the endpoints protected by TLS as required in the specification.

Absolutely. But, are we referring to the development of a client application, or the OAuth2 server itself (Connect, in this case)?

I feel the question at hand is the following:

If an OAuth2 server allowed [only] reserved IP/hostname addresses for the local machine (eg: http://127.0.0.1/... and http://localhost/...) to be registered as non-HTTPS client redirect URIs, would that server be breaking compliance with the OAuth2 specification? Said another way, we'd like to avoid requiring developers to set up their applications to run behind an SSL connection on localhost when developing an application in order to interface with an OAuth2 server, but are hesitant to do so if it would break compliance with the OAuth2 specification.

I don't feel the response above, or the specification itself, clearly answers this question.

[tomkersten]

BTW, @vsimonian, nice work on reaching out to OIDC co-author. Also, the question/wording above could be applied to the OIDC spec instead of OAuth2 if necessary/more clear. ;)

[adalinesimonian]

@tomkersten, I've sent a follow-up e-mail which asks for clarification based on your question.

[tomkersten]

:clap: