diff options
author | William Carroll <wpcarro@gmail.com> | 2020-02-04T22·54+0000 |
---|---|---|
committer | William Carroll <wpcarro@gmail.com> | 2020-02-04T23·00+0000 |
commit | 70034d4cb92a7c3c9c0589e15ee47299d41117e6 (patch) | |
tree | 92b23b53a1d73881c0e805ed228af2cd616dbc2c /configs | |
parent | cce926d60f963ad9e45c0f0b642bcfb3eb86ee65 (diff) |
Begin supporting Monzo OAuth 2.0 login flow
What's done: - Basic support of the client authorization grant stage of the OAuth login flow: - Open Google Chrome to point the user to Monzo's client authorization page. - Created a web server to retrieve the authorization code from Monzo. What's left: - Pulling the authorization grant (i.e. code) from Monzo's request and exchanging it for an access token and a refresh token, which can be used to make subsequent requests. Unanswered question: - Assuming this is a stateless app, where should I store the access token and refresh token to avoid the authorization flow. I'd like to avoid the client authorization flow because ideally I could run this app as a job that runs periodically throughout the day without requiring my interactions with it. Some interesting notes: - Notice how in the .envrc file, it's possible to make calls to `pass`. This allows me to check in the .envrc files without obscuring their content. It also allows me to consume these values in my app by using `os.Getenv("client_secret")`, which I find straightforward. Overall, I'm quite pleased to have stumbled upon this pattern - assuming that it's secure.
Diffstat (limited to 'configs')
0 files changed, 0 insertions, 0 deletions