Adding Blockstack Authentication to a Centralized App

As many of you know, you can sign in to the Discourse instance that this forum is built on using Blockstack ID. I wrote a blog post that goes over the work that needed to be done to enable Blockstack Authentication in a traditional client-server app like Discourse.

I hope this post helps those of you interested in adding support for Blockstack Authentication to your own client-server app.


I wonder if there is a way we could implement Blockstack to be used as an OAuth2 provider. This would simplify it quite a lot, and one could add some custom fields as well to pass on Gaia information if the app requested it.

You could make a server that acts a Blockstack auth oauth2 provider and then apps using that server would be trusting it to identify users.

Not sure how that would simplify things, it would require an additional server or 3rd party service which really defeats the purpose of decentralized identity.


Is the idea to host a atlas node and do local lookup to be decentralized? If using it seems pretty centralized. Why not do OAuth2 in this case?

The idea is that each app chooses their own Blockstack core node. If you’re using this library in a production app, you should probably also be running your own node and configuring own.

You can see that in our Omniauth Strategy, the blockstack ruby library is configured to use the Blockstack Core node specified in the strategy configuration:

What if I have an Android app to integrate? Do I have to implement verifyAuthResponse function on my own, or is there any other way to do it (such as requesting it as a feature in Android SDK :slight_smile: )?

That function should be implemented in thr Android SDK, however in a centralized client-server android app you’d need that logic to exist on your server, not on the client. If authentication logic is on the client the user can trick your server into thinking she is someone else.

In which function it is implemented? I couldn’t find a function with the same name in the SDK.

You can use the handlePendingSignIn method which calls the verifyAuthResponse function as part of the implementation.

1 Like

I think Blockstack as an OAuth provider would be quite attractive. These days I would trust Blockstack more with my OAuth login than I would trust Google. But I can’t ask the various sites I’m registered on to implement a completely new login path. However I might be able to convince them to enable yet another OAuth service, which will require minimal work to change, especially if they’re using some standard auth library like omniauth or hybridauth.

Longer term, once Blockstack’s properly decentralised login is supported by those same cross-service libraries, the OAuth option would gradually be rendered unnecessary.


We have an omniauth strategy available already. Using that strategy directly in omniauth shouldn’t be any more or less work than an oauth-based strategy.

1 Like

Thank you for this article! Was very informative and gave the basis to help move a client-server node app over to blockstack auth w/ server side verification.

Before I ship it, I wanted to clarify one question about the authResponseToken and it’s expiration. When a user signs out of the app with blockstack.signUserOut(window.location.origin), should the old tokens become invalid immediately (that is, returning ‘false’ from verifyAuthResponse), or do they expire after a certain amount of time from their creation, if at all?