-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat(sentry apps): Update the refresh token docs to have manual refresh #15390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 4 commits
5c56a3f
ecf6789
2fce210
5963c38
9394e13
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -108,6 +108,50 @@ def refresh_token(install_id): | |
| return new_token | ||
| ``` | ||
|
|
||
| ### Refreshing Tokens Manually for Integrators | ||
| Sometimes incidents or other technical anomalies can lead to token refreshing being committed on the Sentry side but then the token is lost in transmission on the way back. As a result, we've added a method for integrators to explicitly refresh and request a new token for their installers. | ||
|
|
||
| This manual refresh method uses a different authorization scheme where you will need to send a JWT signed with your client secret to the previous | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a reason for someone not to use this every time to get a refresh token? I mean should we recommend that instead of asking them to refresh after fail?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I thought about this for a bit and I'm not sure tbh, I assume refresh tokens are preffered but yeah this feature does basically the same thing. I'll ask security.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Michelle and I poked into this a bit and it looks like for the Oauth 2.1 spec it's required to have the refresh_token and authorizations grant so we should keep those and have those as preferred. It seems like it would be preferable to move toward the client secret JWT method for authentication as a future TODO. I will mark the refresh_token grant_type/method as preferred. |
||
| `/api/0/sentry-app-installations/{}/authorizations/` endpoint with the below claims and payload. | ||
|
|
||
| ```python | ||
| def manual_token_refresh(install_id): | ||
| url = u'https://sentry.io/api/0/sentry-app-installations/{}/authorizations/' | ||
| url = url.format(install_id) | ||
|
|
||
| now = datetime.now(timezone.utc).timestamp() | ||
| client_secret = "XXXX-XXXX-XXXX" | ||
| client_id = "1234-5678-9999" | ||
| iat = now | ||
| exp = now + 60 # 1 minute validity period | ||
|
|
||
| claims = { | ||
| 'iss': client_id, | ||
| 'sub': client_id, | ||
| 'iat': iat, | ||
| 'exp': exp, | ||
| 'jti': str(uuid.uuid4()), | ||
| } | ||
| jwt_token = jwt.encode(claims, client_secret, algorithm="HS256") | ||
|
|
||
| headers = { | ||
| 'Authorization': f'Bearer {jwt_token}', | ||
| 'Content-Type': 'application/json' | ||
| } | ||
| payload = { | ||
| 'grant_type': 'urn:sentry:params:oauth:grant-type:jwt-bearer', | ||
| } | ||
|
|
||
| resp = requests.post(url, json=payload, headers=headers) | ||
| data = resp.json() | ||
|
|
||
| new_token = data['token'] | ||
| new_refresh_token = data['refreshToken'] | ||
| # ... Securely update the token and refresh_token in DB... | ||
|
|
||
| return new_token | ||
| ``` | ||
|
|
||
| The data you can expect back for both the initial grant code exchange and subsequent token refreshes is as follows: | ||
|
|
||
| ```json | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.