I have a requirement where I need to communicate with Snowflake Sql-Api in the back-end from my application. As I come across the snowflake sql-api documentation, it supports authentication using either oauth access token or JWT token generated with keyvaluepair. For this, I am having a configuration property in my application to configure the access token with customer in properties file.
However, I see that oauth token generated has maximum expire period of 10 minutes and JWT token has maximum expire period of 60 minutes. In our use-case having the shorter expiry period is not feasible as user can't change the properties file regularly and restart my application.
I would like to know what is the way to have access token configured with long expiry period like 30/90 days etc or the way I can communicate with snowflake sql-api as per my use case.
Looking forward to hear from you.
Thanking you in advance.
Related
I am working on a web application that is using Go in the backend and JWT based authentication. When users logged in, I send them access token with a short expiration time and a refresh token with a long expiration time. Both of these tokes includes username as their payload. They are created with different secrets. My question is about log out. When a user sends a log out request, I want to invalidate it's refresh token so that they are needed to log in again after log out. For solution, I am going to store that refresh token in a blacklist table in my database. My question is that should I need to hash that refresh token before storing it in the database. Thanks.
One of the standard JWT claims (RFC 7519 §4.1.7) is "jti", which is a unique identifier for the token. If you include a unique identifier in your refresh token, then it's enough to store the "jti" and "exp" (expiration) claims in the database. (I'd default to using ("github.com/satori/go.uuid").NewV4 to generate the "jti" as a random UUID, and that's internally backed by the "crypto/rand" random-number generator.)
Now if you're presented a refresh token, you can do your usual checks that it's correctly signed and unexpired, and then look up the "jti" in the database. If it's not on the blacklist, then it's good for reuse. You only need to keep "exp" in the database to know when it's safe to clean records out. Since the "jti" is just a random identifier, you can't get back from the "jti" to any identifiable information so there's no particular need to hash or encrypt it.
If you don't have a "jti" and can't add one, I'd probably either hash the token or just keep a copy of the claims. Partly this is for space reasons, and partly you don't want to store something that's actually a valid credential. Keep enough information that you can uniquely identify a token; possibly the "sub" and "exp" time together are enough information (if two tokens issued to the same subject expiring at the same second are indistinguishable).
As far as web applications are concerned I know I can refresh/reissue the JWT by setting another parameter expireUntil in JWT with some duration and check it in each subsequent request and if it's not expire I can reissue the token or something along those lines. I don't know how efficient it is or if it's the right approach but that's the one I had in mind. Secondly I could also do it on the front-end by keep looking at the expiry time and resend the request to reissue it if it's about to expire. Anyway, the idea is to not let the user sign off if it's continuously making requests like in old session era.
Apart from that, the major question is how mobile application keeps the token alive forever. I don't think I was ever signed out of my Uber or foodpanda app even if I'm offline for days. How do they do it in case of mobile apps? Do they simply set the token expiry to some really large arbitrary value or some other way to authenticate and reissue the token because I know I can't do that with the approach I listed in above paragraph as if the user remains offline for a day my token will expire.
Any ideas how can I do that?
I need to make an Apex Callout to Marketing Cloud when a Lead is created in Salesforce that matches certain criteria. I would like to use this MC Rest API - https://www.exacttargetapis.com/messaging/v1/messageDefinitionSends/key:Autoemail/send. The issue then is that I first need to authenticate with MC to get an Access Token to pass when making the above API call. Does anyone have a good way to persist the Access Token in a Salesforce org? I'm thinking of storing it in a Custom Setting and only updating it when an Apex callout goes to use it and sees that it's nearly 60 minutes old. Is anyone doing something similar? Thanks!
If you know that access token to external service can be expired and should be updated sometimes automatically, the better approach is which you choose - custom setting (or custom object for storing it).
If this token can be hardcoded one time and it will not be changed for a long period, you can checkout Authentication Settings for External Systems functionality.
I'm developing a web-frontend to configure a hardware device (almost like a router), wich runs a nodejs backend to serve an Angular Frontend for Configuration. I use JWT to secure stateless requests to the backend. One feature is to set the system time via the Frontend, by issuing a command to the backend, which sets the local machine time, to deal with timezones. Problem is, when the time change is more than the 30 min in the past, the user gets logged out due to session timeout. What would be the best way to solve it? My approach was to set the timeout to indefinite, change system time and change the timeout back to 30 min, using a refresh token. Any other ideas? Thanks.
If you ask me, using expiration time in JWT when system time can change does not make sense. So my options would be:
- Do not use expiration time at all
- Use refresh tokens
- Revoke all issued tokens
- Time history: Accept the old tokens by calculating the date they were issued. You can know when a token was issued by adding a unique and incremental jti identifier. When system time changes, store the current jti value and the difference between old and current time
jti - time diff
You can empty the list when the maximum expiration time is exceeded
You could implement a refresh token. So whenever the access token expires, the user can request a new access token, using the refresh token.
For a calendar app, I want to sync users calendars (events) to my database. For now, I need title, start, end, recurrence and reminders/alerts. I am thinking, I will get these information from app and store it to a database. To make things easy (implementing recurrence maybe hard), I thought of using a hidden Google Calendar account on the server as a database.
Server will use a "hidden" Google Calendar account
App (iOS) will get calendar information from user's iCal via EventKit
Passes server this information which is saved to Google Calendar
So 1 user calendar becomes 1 hidden google calendar
But I think I might encounter some problems with API limits?
I might need to re-authenticate to refresh the access token? Is there a token I do not have to refresh?
Is the limit on the number of calendar I can have 10,000? What if I need more? Isit even possible? Or is it 10,000 for "a short period of time".
Is this possible? Or is the only option a self build system.
The quota for the Google calendar API is Queries per day 1,000,000 if you go over that you can always request additional quota as far as I know it doesn't cost anything to extend your quota.
Once you have authentication to a user Google calendar account you will receive a refresh token. The refresh token can be used to gain a new access token when ever you need to access it. Refresh tokens don't expire unless a user removes your access.