API Authentication
About access_tokens
See here for complete coverage.
Though a little explanations will not hurt so here they are:
Add-on token or User token Retrieval
They are automatically generated and retrieved after installations (in case of User tokens, upon users’ approval, at least) .
To do that with this library:
Prepare your Add-on server with:
Installation Flow handling logics, which involves:
- Capability descriptor endpoint URL
- Stable storage for
client_idandclient_secretper installation
- (For User token) Callback URL to which users are redirected after approval
- Create an OAuth client struct (
Hipchat.OauthClient.new/3) with generatedclient_idandclient_secret. Create a body which must include
grant_typeand other requirements.grant_typeshould be:client_credentialsfor Add-on tokenauthorization_codefor initial retrieval of User tokensrefresh_tokenfor refreshing User tokens
- See here for details.
- Request with OAuth Sessions API function.
Hipchat.OauthClient.new("client_id", "client_secret")
|> Hipchat.V2.OauthSessions.generate_token(%{grant_type: "client_credentials", scope: "send_notification"})
# {:ok, %Hipchat.Httpc.Response{body: "<should contain access_token>", headers: ..., status: 200}}
- Your server have to store generated
access_tokens (andrefresh_tokens) for later uses. If they expire, re-generate or refresh.
User generated tokens
After logging in to HipChat, you can manually generate Personal Access Tokens with arbitrary access scopes,
or room-only Notification Tokens.
They are convenient because, (1) they do not require automatic installation logics on your server and, (2) they are semi-permanent (year-long expiration as of 2016/12).
If you just need notifications or other limited-scope actions in your Add-on or Bots, they come in very handy.
Be sure to properly control visibility of those tokens. They must be visible only to their owners and trusted third parties, as with any other similar API credentials out in the world.