Here is what I am planning to to for keeping separate tokens for web and mobile
1.When user is logged in from web JWT token is issued and it is stored in DB table with created time stamp.
The above step is repeated for the mobile client ,so the table contains separate tokens for each client.
2.At the time of validation search for the token in table and validate if exists then it will try to verify with JWT.verify
Is it right method to do keeping separate logins using JWT??
Maybe there are other ways to do it, but your approach is totally correct. By fact I would recommend it exactly your way. What you doing, is scoping issued token for specific service, platform. It is useful not only for your use case, but also when you have multiple APIs. You can issue different tokens for each service separately.
Related
Im trying to create an applet in IFTTT however i need to obtain an auth token to allow the lights to call the service each time.
Im trying to obtain an auth token via the below:
Account information
GET Request auth token
https://environexus-us-oem-autha1.mios.com/autha/auth/username/{{user}}?SHA1Password={{sha1-password}}&PK_Oem=6&TokenVersion=2
The Nero API is RESTful and stateless and therefore requires authentication tokens to accompany every request. Once these tokens are requested they can be stored in a database for quick reuse.
This is the intial request to the API servers that collects the tokens and various IDs required for all subsequent calls. Tokens are valid 24 hours but should always be checked against the response in case this changes.
Request
{{user}} is the portal login
{{sha1-password}} is the hash of:
sha1(lowercase({username}).{password}.oZ7QE6LcLJp6fiWzdqZc)
(concatenated together - no additional characters should be inserted,
salt at end is static for all accounts)
PK_Oem and TokenVersion are static and provided above.
However im not sure what to put in for the "sha1-password"section.
Any help would be appreciated?
You need to calculate the SHA1 hash for the information above, which is the username, password and 'static salt' concatenated together with each value separated by a period.
Don't know what language you are using but most languages have libraries that will do this for you (e.g. Apache Commons library for Java)
This API is not particularly well designed in this respect, as client side hashing does not bring any benefits (when transmitting over HTTPS) and the 'static salt' as they call it is utterly pointless, as it's public.
We are using G Suite API with our Micro service for document editing, and we have a different data center and also different db. now once user comes to my application and trying to open document first time then google give consent screen based on that i can get refresh token and access token and i store into one data center.
But problem is that if user comes from another instance which use different data center with different db and user trying to open document with old credentials then google doesn't give any consent screen so i am not getting user's refresh token.
1) So is there any way to get refresh token without using consent screen?
2) Is there any way to identify if user comes from different sub domain then i need to provide consent screen for that?
It might be possible to use the prompt=consent option to force a re-prompt for auth, even though the user has already authorized your app.
See https://developers.google.com/identity/protocols/OAuth2WebServer#creatingclient
You can identify the user's domain using the hd parameter [1] and you can request a refresh token without the consent screen after the domain admin has configured domain wide delegation by installing your application from the GSuite Marketplace [2].
[1] https://developers.google.com/identity/protocols/OpenIDConnect#hd-param
[2] https://support.google.com/a/answer/172482?hl=en
When you request an OAuth Flow (access_type=offline`), a Refresh Token is returned to your application. This only happens once (obtaining a Refresh Token). Your application is expected to save the Refresh Token for future needs.
In your use case, one of your systems completed the authentication and the user has moved to a different system. You will need to reauthenticate with prompt=consent, access_type=offline. You will not get another Refresh Token without reauthenticating.
I spent a lot of time on this issue last November. Here is a link which has lots of details on this problem.
Any application can only have one valid refresh token for a user. You can request for a new refresh token using the prompt=true&access_type=offline on the request as said by #John. But every time the previous one will become invalid.
Based on you comments on the other answers, I'm assuming creating a new micro service that returns the token to the one being used is not a possibility (that would be my recommendation)
You asked "to identify if user comes from different sub domain"...
If those applications are for end users of gmail.com accounts, you can treat them as different applications and configure different projects on the developer console.
It will be a bit of a pain when enabling new APIs, I would recommend doing that from a script that replicates to all application needed.
If your end users are from companies using GSuite, you can have your app installed as domain-wide application (either manually or from GSuite Marketplace). In that case you can use just client side authentication to get an id_token, send the token to the server and use a service account to impersonate the user in any given service without worrying about any token from them.
I am working on an Identity management application, using which my goal is to manage users on Box application.
I was going through Box documentation, and there are two ways for authentication
OAuth 2.0, which has redirection URI as required parameter. And due to which I cannot make use of it, since I will not be able to enter username and password and Authorize dynamically using my Java code.
Reference: https://box-content.readme.io/reference#oauth-2
JWT authentication, this I can use in my code and successfully get Access token. But problem here is, this access token can only be used to manage App Users (who will not have login to Box website).
Reference: https://box-content.readme.io/docs/box-developer-edition
So, is there any other authentication mechanism which I can use for getting Access token for managing Box users?
Regards,
Sandeep
The current best option is #1 with a process like this:
Create a Box application with the 'Manage an Enterprise' scope enabled.
Use a web-based access token generator (such as this or this) to get an initial access/refresh token pair. Save these somewhere safe (flat file, DB).
Code your application to initialize itself with the access/refresh token pair from its saved location.
When the access/refresh token pair is refreshed, write them out to the save location.
If your application runs across multiple nodes/processes this approach will require some (painful) coordination between them. I believe Box is working on some improvements in this area, so you may not have to live with this for long.
We are planning on migrating our Box v1 integration to v2.
Our integration implementation includes API calls accessing user box account and files from different servers at the same time.
With v2, and the introduction of refresh token, we would like to know whether multiple refresh token requests can be made concurrently from multiple servers over the same user account.
Moreover, and as a consequence of multiple refresh calls, we would also like to know whether it is possible to have more than one access key per user at any given time.
Thanks for the help
Assaf
We recommend that you use some sort of coordination between your servers to manage auth tokens and refresh tokens. While a user can have multiple access tokens for the same service, they will have to authenticate multiple times in order to get them. You can't mint extra auth tokens off a single auth-token/refresh-token pair.
Here's what we recommend.
Create a pair of encrypted columns in your database to store the auth token, the refresh token, a datetime for "token_expires", and a flag for "token_refresh_in_progress". Identify it by userID.
Write your code so that when you are about to make a call, if you are close (say, within a minute) of the token-expires datetime, instead of making your call, you check to see if the refresh-flag has been set, or if there's already a new token pair. If the flag hasn't been by some other server in the cluster, set the flag that you are doing the refresh. Make the refresh-grant call, and update the database with the new pair, and of course reset the flag.
I have an iPhone application that needs to collect data from an online MySQL database. I've written a PHP web service so I collect the data with JSON. The problem is that everyone can see the data if they go to the URL now. How do i secure the data transfer properly?
Thanks for your suggestions.
Typically, if you are showing data private to a particular user, then each user will generally have an account (user id and password). The app will pass the user's credentials to the server before the server will provide the user's data.
You can also do something similar using SSO integration, or OAuth (ala Facebook).
In some cases, your app may only pass the username/password on the initial call and receive a session ID, which the app passes on remaining calls. This allows the server to store session data.
Even if the data isn't private to a particular user, you can use accounts to restrict access and privileges for a publicly reachable web API.
In all of the above cases encryption such as SSL (HTTPS) must be used to protect the authentication mechanisms and data transfer.
I'm assuming your data is public for all users of your app, in other words, you don't want to implement a login mechanism for your users. If you just want to make sure you return the data only to users of your app and not to anyone who happens to enter the right URL in their browser, you will need to sign your requests, so that only requests from your app are accepted by your server.
I use a secret key that my app uses to create a hash/digest of the request which the server verifies (it knows the secret key as well). Also I make sure requests cannot be replayed if they are intercepted by adding a timestamp and a nonce. The timestamp is checked to be within 10 minutes of the server's timestamp (relaxed sync) and the nonce must be unique (server keeps the last 10 minutes of nonces). This way no-one can copy the same request, the server will just serve an error if they try.
This post explains how to sign your requests in a bit more detail:
http://www.naildrivin5.com/blog/2008/04/21/rest-security-signing-requests-with-secret-key-but-does-it-work.html