Adding Blockstack Authentication to a Centralized App

larry · September 14, 2018, 12:59pm

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.

MichaelFedora · September 14, 2018, 9:16pm

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.

larry · September 15, 2018, 2:56am

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.

igor1992 · September 15, 2018, 7:50am

github.com

blockstack/blockstack-ruby/blob/e5a209c8ed37a2960b33ef5023ff69acb0fdee86/lib/blockstack.rb#L16




module Blockstack
class InvalidAuthResponse < StandardError; end


USER_AGENT = "blockstack-ruby #{VERSION}"
ALGORITHM = 'ES256K'
REQUIRED_CLAIMS = %w(iss iat jti exp username profile public_keys)


DEFAULT_LEEWAY = 30 # seconds
DEFAULT_VALID_WITHIN = 30 # seconds
DEFAULT_API = 'https://core.blockstack.org'


def self.api=(api)
  @api = api || DEFAULT_API
end


def self.api
  @api
end


def self.leeway=(leeway)

DEFAULT_API = ‘https://core.blockstack.org’

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

larry · September 17, 2018, 8:44am

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:

github.com

blockstack/omniauth-blockstack/blob/330f9db479414183c7563591fb15cd545069214d/lib/omniauth/strategies/blockstack.rb#L67


  header_info << "<script>#{auth_request_js}</script>"
  form = OmniAuth::Form.new(:title => "Blockstack Auth Request Generator",
  :header_info => header_info,
  :url => callback_path)
  form.to_response
end


def callback_phase
  auth_response = request.params['authResponse']


  ::Blockstack.api = options.blockstack_api
  ::Blockstack.leeway = options.leeway
  ::Blockstack.valid_within = options.valid_within
  @decoded_token = ::Blockstack.verify_auth_response auth_response


  super


rescue ::Blockstack::InvalidAuthResponse => error
  fail! :invalid_auth_response, error
end

altuncu · September 17, 2018, 9:45pm

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 )?

larry · September 18, 2018, 6:21am

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.

altuncu · September 18, 2018, 1:39pm

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

larry · September 18, 2018, 5:06pm

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

github.com

blockstack/blockstack-android/blob/4cfcab8d5302c0037cdf13d9946792eb1fdaa578/example/src/main/java/org/blockstack/android/MainActivity.kt#L248




private fun handleAuthResponse(intent: Intent) {
    val response = intent.dataString
    Log.d(TAG, "response ${response}")
    if (response != null) {
        val authResponseTokens = response.split(':')


        if (authResponseTokens.size > 1) {
            val authResponse = authResponseTokens[1]
            Log.d(TAG, "authResponse: ${authResponse}")
            blockstackSession().handlePendingSignIn(authResponse, { userDataResult ->
                if (userDataResult.hasValue) {
                    val userData = userDataResult.value!!
                    Log.d(TAG, "signed in!")
                    runOnUiThread {
                        onSignIn(userData)
                    }
                } else {
                    Toast.makeText(this, "error: " + userDataResult.error, Toast.LENGTH_SHORT).show()
                }
            })

erlend_sh · October 9, 2018, 1:57pm

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.

larry · October 9, 2018, 2:24pm

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.

zac_denham · January 7, 2019, 8:10pm

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?