Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
How to integrate OAuth2 on Web 3.0 apps?
In order to integrate Hivesigner into your application, you will need Hive account.
If you don't have one yet you can create one on signup.hive.io in with your app account.
After you have your account, go to https://hivesigner.com/profile and login with your app account and update account type as "Application"
.
If you would like to use the OAuth 2 API for posting with HiveSigner server, you need to authorise the Hive account "hivesigner"
to post on the behalf of your app account. Click here to do this and sign with your app account.
You can edit your app settings by updating your app account profile. Edit app settings, add avatar for your app, define redirect URIs for your OAuth2 integration. Make sure your application/website handles redirect URIs correctly.
That's it, after above steps, you should be able to write OAuth2 logics and start integrating transactions signing.
Hivesigner provides you traditional REST API to interact with blockchain and handles all cryptography and transaction signing for your app and users. Some examples are given in /hivesigner-oauth2
We have created extra Swagger documentation with Hive blockchain functions so that you can quickly and easily interact with blockchain data, fetch, reformat, learn required parameters, etc.
Community contributors also created Python wrapper of Hivesigner SDK that you might want to try.
Imagehoster is that helps you to proxy user uploaded images and allows you to create easy user authenticated image uploads with extra benefits (rate limiting based on reputation, blacklist, etc.)
There are couple instance of imagehosters run by different teams, and separately maintained/hosted instance of Imagehoster. You can also start your own instance easily by following and guides.
If user login to your app with Hivesigner, you can verify user and accept their uploads by utilizing techniques used by Imagehoster, above instances does that and verify access_token
for uploads.
POST /hs/:accesstoken
Above endpoint takes access_token
and verifies if it was created by same app, in above instances, @hive.blog
and @ecency.app
, when you setting up your own instance of imagehoster, your users in your app will be able to verify and upload images to your instance. Below is code section to show how verification is done.
This is simple verification method use only app accounts to verify access_token
and validity of user.
Name
Language
Author
Python
Python
More advanced backend security could also be achieved with access_token
from hivesigner. You can make sure only user you want can access certain content, this way you don't have to add your own security layer just utilize what Hivesigner already provides you.
Below simple code makes sure that access_token
is indeed signed by user. And checks to makes sure keys matches perfectly.
This combined with Imagehoster verification is perfect combination of security you can get in your app to serve user specific pages like drafts, bookmarks, images, etc.
Join our discord where many community developers and members helping each other or reach out Ecency team to report bugs/issues.
If you are developer, feel free to check Hivesigner Github repositories to help us out, any suggestion, bug report, feedback is very appreciated.
Yes, OAuth2 allows you to communicate, authenticate, sign transactions with ease, simple standard REST APIs.
Our official SDK is written in Typescript and available in NPM package manager.
You can install JS SDK into your Nodejs or Browser based apps easily.
npm install hivesigner --save
or
yarn add hivesigner
What's OAuth2 ?
OAuth 2 is the industry-standard protocol for authorization. OAuth defines four roles:
Resource Owner: User Client: Application Resource Server: hived Authorization Server: Hivesigner
The implicit grant flow basically works as follows: the user is asked to authorize the application, then the authorization server passes the access token back to the application. The implicit grant type is used for mobile apps and web applications where the client secret confidentiality is not guaranteed. This flow does not authenticate the identity of the application, and relies on the redirect URI to serve this purpose.
Step 1: Implicit authorization link
With the implicit grant type, the user is presented with an authorization link, that requests a token from the API. This link looks like this:
Step 2: User authorizes application
When the user clicks the link, they must first log in to the service, to authenticate their identity (unless they are already logged in). Then they will be prompted by the service to authorize the application to post on their behalf.
Step 3: Application receives access token
If the user clicks authorize the application, the service redirects the user to the application redirect URI, which was specified during the client registration, along with an access token. The redirect would look something like this (assuming the application is "example.com"):
For get offline permission you need to use the code authorization flow and add scope "offline" along with the other permission you need. You would send your user to a page like this: https://hivesigner.com/oauth2/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&scope=offline,comment,vote,comment_option,custom_json
You will then receive a code which can be used to get a refresh_token
. Refresh token does not expire and you can create access_token
anytime with it. With the code you will need to send request to Hivesigner API at https://hivesigner.com/api/oauth2/token?code=THE_CODE_YOU_GOT&client_secret=YOUR_APP_SECRET
This request must be made from your server, don't make your app secret public. Also its recommended to send code and secret inside body of a POST request, instead of GET request with url param.
Scopes provide access to certain operation. The application service should only request scopes it requires.
Once the application has an access token, it may use the token to access the user's account or broadcast posting operation via the API, limited to the scope of access, until the token expires or is revoked.
Here is an example of an API request, using curl
. Note that it includes the access token:
Broadcast a transaction
Here is an example POST request, using access token to broadcast a vote for user:
Response:
Name
Description
login
Verify Hive identity
posting
Allow posting operations
There are some cases where you don't need Posting Authority on your apps.
Couple examples are https://hivesearcher.com and https://openhive.chat where use case and actions are off-chain, no on-chain operations or transactions are signed.
Hivesearcher and Openhive.chat allows you to login with Hive account and perform actions without any chain operations. This is perfect use case for off-chain applications. Essentially, making any Web 2.0 application Web 3.0 by using Blockchain for Authentication.
There are more benefits of using hybrid approach. Try these approach and let us know if you are able to secure your apps to the best of your ability. Giving people complete control over their keys while still allowing services, websites and applications to serve everyone in most secure manner.
How Hivesigner login works?
Hivesigner allows you to sign transactions most secure way, so that applications you are using won't have direct access to your private keys while allowing you to perform actions within defined scopes.
When you login to Hivesigner, your private key is available within the interface to sign transaction and message, keys never leaves the browser. We never have access to your private keys. The access_token
on Hivesigner are just simple message signed with Hive private keys and encoded in base64u. User Interface (UI) gives you easy way to handle your authorities and keys.
Code is here: https://github.com/ecency/hivesigner-ui
When you login to a website like https://ecency.com, https://hive.blog, https://peakd.com, etc. using Hivesigner, you are requested to Authorise the relevant Hive account @ecency.app, @hive.blog or @peakd.app which broadcasts posting operations on your behalf. This is a feature supported by the Hive protocol.
If you go here https://hivesigner.com/auths you can see which account(s) you authorised and which authority you give them. The Hivesigner API hold the hive account @hivesigner posting key, when you cast a vote on Ecency, Hiveblog or Peakd, access_token
is being sent from those applications to Hivesigner API, the API then verifies that token, if it's valid, transaction is broadcasted using @hivesigner posting key.
This is possible using double delegation of posting authority, for example @bob
authorize the @ecency.app
account to do posting operation on @bob
behalf and @ecency.app
authorise @hivesigner
to do posting operation on @ecency.app
behalf.
This flow is perfect for security and at any moment your keys are safe from malicious apps.
Code is here: https://github.com/ecency/hivesigner-api