msgraph-sdk-ruby
msgraph-sdk-ruby copied to clipboard
How to persist access tokens?
Hello,
I'm currently trying out the latest Microsoft Graph Ruby SDK and need a few pointers on how to approach my use case. I'm planning to access Microsoft Graph API through a Ruby-backed webapp which I'm hoping I could build Microsoft Account linking feature.
After reading the main docs and kiota-authentication-oauth-ruby source code, I managed to obtain a temporary auth code which I applied to MicrosoftKiotaAuthenticationOAuth::AuthorizationCodeContext. I then created the adapter and client instances as per the docs and I was able to make requests to with client.me.get.resume.
I understand that the library is in community-preview, but my questions are:
- I couldn't seem to find any method to expose the access tokens (I assume) automatically retrieved through
context.get_tokenand after using the client once, the auth code can't be used anymore to get the same access token. What's the recommended approach to persist tokens say with Redis? or is the SDK/Microsoft Graph API meant for short-lived sessions? (Sorry I'm not too familiar with Microsoft Graph) - Is the REST way still the recommended approach to use Microsoft Graph at the moment?
Thanks.
Kind regards, Ricky
Hi @rcklmk Thanks for using the ruby SDK and for reaching out. Generally we discourage people from storing access tokens, they are a security liability (in case the storage gets accessed) and it makes the application brittle (no renewal possible in case of expiration/invalidation). Here is the guidance we provide for scenarios:
- giving the ability to the user to stop/pause the app and re-open it without requiring them: use a refresh token instead.
- caching to avoid making requests to the identity provider and reduce latency/throttling: use a library that implements caching in a secure store (TPM etc...) or do it in memory only.
The only case that could be considered valid for access token storage would be in the case of having multiple front-end backend instances, no affinity for client connections on the load balancer, and a back-plane to maintain state between instances. In that case you can most likely implement a proxy design pattern with the Access/Authentication Provider interfaces to do so.
I hope this provides enough context, let us know if you need more information.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.