ranisputnik / sqrl-go

Go implementation of the SQRL protocol

SQRL

An implementation of the SQRL protocol, designed to be easy to integrate into a http server or SQRL client.

This is not production ready, please proceed with caution.

Simple Quick Reliable Login (SQRL) is a protocol designed and formalised by Steve Gibson of the Gibson Research Corporation. Visit his site for more information about the SQRL.

SSP Example

The SQRL Service Provider (SSP) example is based on Steve's own example at sqrl.grc.com. To run the sample use the following;

$ cd ssp/example
$ go run *.go

sqrl-go's Issues

Use websockets instead of having the browser ping the pag.sqrl endpoint

As an enhancement to #20 we can improve on the pag.sqrl polling system (in Steve's example) with a sample that uses Websockets for the transport, allowing the server to push updates and provide more immediate feedback to the user.

This could fallback to the polling system if websockets are not supported in the users browser.

Update the go package to a go module

Go Modules are likely to be the way Go packages are versioned in the future, we should move off dep and instead write a Go module instead.

gifProbe is not defined

When I click the "Sign-in with SQRL" button an exception is raised

ReferenceError: gifProbe is not defined

Presume this is a really easy fix - haven't yet investigated.

Do all client messages start with version parameter?

There is a problem when authenticating with the web extension.

Currently, we send a client failure because we fail to parse the message from the web client. The parsing fails because the web extension does not provide the version information as the first key in the client message.

I don't know whether this constraint should be relaxed on our side or if this should be fixed in the web extension.

Return a CPS URL in response to ident command

The SQRL web extension expects a url returned as the result of an ident query, which it will use to redirect the browser, however I believe this is the job of the polling Javascript on the page.

I have opened a thread on the SQRL forums seeking clarification https://sqrl.grc.com/threads/url-returned-to-client-vs-polling-javascript.527/

Causes COA (Cross-Origin Authentication Attempt) Error in Chrome SQRL Extension

Not sure if this is something that is incorrect on our side or in the extension, but in version 0.0.34 logging in to the SSP example causes a COA error https://github.com/Jaaap/SQRL

iOS client fails with invalid content type

The iOS client v1.0.281 (8362) fails to authenticate with the SSP server complaining that the response should have content type application/x-www-form-urlencoded. I'm not sure exactly which request triggers the failure, will require further investigation.

Response Endpoint Should Be Configurable

In a SQRL response, in the server parameter we must return the qry parameter. eg.

ver=1
nut=bRW-IegCUhGmcz9yvTtDKA
tif=5
qry=/sqrl?nut=bRW-IegCUhGmcz9yvTtDKA

In our current SSP example, the cli.sqrl URL is actually prefixed by with sqrl, but we use http.StripPrefix https://golang.org/pkg/net/http/#StripPrefix to remove it. Because of this, the SQRL server can not automatically detect where it should send the client next.

Should we instead add an "endpoint" property to the SQRL server which allows consumers to tell the server where they expect clients to make requests to?

Make Endpoints Configurable

When a sqrl exchange is completed the users browser / mobile device needs to receive a token that can be used to prove the sqrl authentication was successful. This token return URL should be configurable.

There is also a qry parameter returned in the server response, the endpoint used in this parameter should also be configurable to allow for gateways or proxy infrastructure that may modify the URL.

Allow Cross-Device Login with pag.sqrl Endpoint

When logging in by scanning a QR code, there's a good chance the mobile client that scanned the QR code can not instruct the users browser to perform a redirect. To handle this scenario the browser can ping the pag.sqrl endpoint intermittently to discover the redirect URL.

In order to do this we will need to start storing sessions in some way on the server, so this will be a good excuse to start establishing a data model. For now we will work in-memory, but we can use an interface that will allow for adapters to different database technologies (eg. Redis).

When is a Identity Considered "Known"?

The SQRL server must set the TIFCurrentIDMatch and TIFPreviousIDMatch flags if the current identity or previous identities are known. Unfortunately the spec isn't very clear on what it means to be "known", is that after the first successful query transaction? Is it after the first completed ident / successful login?

Will need to clarify this and document in the ssp.Store.GetIsKnown(ctx, id) method so that implementors of the ssp.Store interface are given guidance on when this method should return true.

Make testing easier by providing command line utility for generating fake identities

Writing the tests for the SQRL transactions would be a lot easier if I had a tool that could sign arbitrary payloads with a known identity.

Add Loading Spinner As Login is Processed

When the client begins to query the server it would be good to add some visual feedback on the browser page to indicate that something is happening. This would be especially effective in a cross-device scenario where you can see loading bars on both devices as they appear to "sync up".

This would be most effective for CPS logins, or if websockets are used for pushing authentication state updates to the browser as described in #21.

We could do this by using three states for the paging endpoint / websocket messages eg.

404 - Not Found // No session in progress
202 - Accepted // Client authentication in progress
302 - Found // Authentication complete, redirect the browser

This should be considered an enhancement to #20

Nut endpoint should match reference SSP server

Currently the nut endpoint is exposed at /nut.json and returns JSON in the response. In the reference SSP server, this endpoint is exposed at /nut.sqrl and returns the nut in plaintext in the response body.

We should aim to match the SSP server's functionality for easier client side integration (folks should ideally be able to use the JS that Steve has provided in the reference implementation).

Remove hardcoded domain from sqrlapi.js