For example if i have build a mobile application and using the nodejs REST api for accessing the backend.
I want to restrict the access of the application with same login credentials on a maximum of two devices.
For example me and my friend can have have access to the application with same login credentials but a third friend must not be allowed to have access to the account with same login credentials.
Can it be implemented with some kind of token. Can anyone please help me in understanding the concept to implement this.
Posting as an answer, since it does appear to be a solution.
It can be implemented with a token, but I think it's important here to maintain sessions. Also, you need to keep track of who is connected to what account, and from what device. You'll definitely need unique identifiers, and to know how many logins the account is already utilizing. If a user logs out, remove that device from the list until they login again. Read up on session management. I have had good success using PassportJS for stuff like this :)
Related
Ive been researching the MS Graph API lately, and I'm running into a problem. My use case is that I want to read a certain mailbox's mail, and send mail for that mailbox. The mailbox is a non user related box, and is used as a service account for emails.
Ive found 2 possible flows for getting into that mailbox. The user authenticated flow, and the application (and admin consented) flow. For the application, I want to read the emails in the background in a NodeJS app, without user interaction.
When I look into the user consented flow, I find that to make it work the user HAS to log in atleast once, by hand, and consent to some stuff I want to do. I found this page, on how this works, and made it work in my NodeJS app. The problem is, when using this flow, I have to login BY HAND atleast once after starting my NodeJS app. Afterwards I can use the refresh token to refresh the access token, but I dont want to do the login by hand.
The second option, and most suitable option for my NodeJS app, is the application flow. I found this tutorial on how to do that, and I made it all work. I fetch a token, and that token grants me access to the box via the Graph API.
But using the application flow, I found that I have to have the roles (i.e.): "User.ReadAll, Mail.Read, Mail.Send". This gives my application rights to read and send mail FOR ALL users in the account.. Which is WAY too much overkill for my situation.
Now my question; Is there a way for me to use MS Graph, with the application authentication flow, but without having access to all users' mailboxes, only to my specific account I want to read?
Thanks in advance,
Caspar
While linking the documentation reference, I saw that I read over the most important footnote:
Important Administrators can configure application access policy to limit app access to specific mailboxes and not to all the mailboxes in the organization, even if the app has been granted the application permissions of Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.Read, or MailboxSettings.ReadWrite.
So it is possible using the application access policies.
I'm using the express-stormpath package with a new application I've created in my account at Stormpath.com.
I use stormpath in my app I have to provide an application HREF provided in the application page in the stormpath admin, I also have to provide a API Key and Secret.
I've been creating a new API key/secret for every app I've made on the one admin tenant assigned to the account, the one I signed up with.
And I use that API key/secret to authorize my express application with Stormpath.
So in my admin account I have a long list of API Keys and I have no idea which key is for which app.
Is this how I should be doing it?
It just feels very messy. I see that normal application users can be given API keys/secrets, what are these for? Can I create an admin users for each app and use their API keys and secrets without making them a stormpath administrator?
Does that make sense? I've tried emailing the support directly.. but they didn't really understand any of this. :/
First of all, this is a great question, so I’m not sure why you’re being down voted. API keys can be a confusing topic. I’ll try to clear up the mystery around them before answering your specific questions.
In Stormpath, there’s two types of API keys: Tenant API keys, and Account API keys. Tenant API keys are what you need in order to make API calls to Stormpath. They identify you as an administrator of your Stormpath Tenant, and give you full read/write access to all of your Tenant’s data (in other words, anything and everything you’ve stored in Stormpath). By definition, an administrator has access to the Stormpath API and the Admin Console (aka the webpage you see when you log into Stormpath).
There’s also the notion of Account API keys. Accounts are people (or devices) that are signing up to use your web app, mobile app, or API service. In Stormpath, Accounts are stored in Directories, which in turn are stored in Applications. You can read all about this here. I like to think of Account API keys as a more secure version of a username and password. They’re really useful if you’re building out your own API service and want users to authenticate before they start making requests to your API.
That’s really all there is to it. API keys authenticate you — nothing more, nothing less. There’s tons of articles out there debating whether or not API keys are more secure than other methods, so you’re free to check those out. But in Stormpath, in order to communicate with our API, you must identify yourself as a Stormpath Tenant administrator. As you build out your own web app, mobile app, or API service, you can choose how you want your users to interact with your services.
I hope this helps clear things up.
If you want to create any other type of roles/permissions for your users, you’ll need to learn about authorization and how it works in Stormpath. I won’t elaborate on that here, but you can read all about it in our docs.
I have managed to create an iOS app that successfully authenticated the user and connects to the Nest structures and device settings. Using the access token, the app connects automatically to the Nest server each time the app is launched.
However, I am unable to find any documentation that explains what procedure to follow if the app needs to provide the functionality to enable log on/off for different user accounts, e.g. monitoring devices at different locations under separate user accounts from the same app.
The only way that I can change the login for a different user at this time is when I delete and re-install the app, which is not practical.
Does anyone have a suggestion as to how to solve this issue?
Your help is much appreciated.
You'll want to just create a routine for getting the access token that can be reused. The login is part of the authentication process in retrieving an access token.
Once you have an access token, there isn't any open session per user account so there isn't a need to logout. Instead, just reuse the same method that got you the first access token and store as many access tokens as necessary.
Each access token is effectively a session id.
I'm trying to use Windows Azure Access Control to avoid the security risks in using usernames/passwords in my app and to simplify the authentication. However, this is a site that can be used by medium or large companies that may wish to "pre-authenticate" users. In other words, they may want to bulk create users by putting in the users' Windows Live IDs and create their accounts automatically, before that user has ever signed in through Azure ACS. I could accomplish this by sending that user an email with a link to a one-time-use page to create their account, but I am hoping to do something a little more seamless.
What I'm trying to do is equivalent to how Team Foundation Service (*.visualstudio.com) lets you add users to a team project just by putting in their Windows Live IDs and once you do, they can log in and access the project, even if that user had never signed in to TFS previously.
What I don't understand is how to do that using ACS and System.IdentityModel. I can use the nameidentifier claim to uniquely identify a user, but how do I get a nameidentifier for another user through a given provider?
I'm sorry if I'm not explaining this well, so feel free to ask questions.
Not really an answer but just wanted to share my thoughts on the issue.
The problem with ACS and Windows Live authentication is that ACS never returns the user's email address. All we get back from ACS is a token telling me that the user is authenticated. This token is created based on your ACS realm (i.e. if you change the ACS realm, a new token will be created by ACS for the same user). Again, the admins of the company who are using your application can enter the email addresses of the user but there's no way to get that email address back from ACS.
Just thinking out loud :), there're a few things you could do:
You use ACS for authenticating the user and then use Windows Live REST API to get more details about the user using the token sent by ACS. By using Windows Live REST API, you can get more details like name, email address etc. about a user. Or you could use just Windows Live API for authenticating the user. I'm not 100% sure but I think this is what Team Foundation Service does. Do take a look at http://zud.io as it does the same i.e. uses Windows Live API.
Another idea would be to create some sort of invitation tokens. In this approach, admins would "invite" folks. They would create invitation record by providing the name, email address of the users and the application would create unique invitation tokens. The application could then create an invitation link using which users would come to your application and authenticate themselves. Once authentication is done, you could look up the invitation record and retrieve user information from the database and create user record and associate the authentication token with the user record. The issue with this approach is that a user may not use the same Live Id as provided by the administrator. For example, I have at least 3 live ids and if I have that invitation link, I could sign with any of those live ids and the application won't be able to stop me from registering.
Yet another idea would be to use Windows Azure Active Directory (WAAD) instead of ACS. You could consume Graph API in your application to create new users for your clients. You're still not managing user names and passwords as that is done by WAAD. The two issues I could think of there are - a) As an end user, I have to remember one more username/password combination and b) At the time of login, I have to provide my credentials in myusername#yourtenantname.onmicrosoft.com which to me personally is a big hassle.
We too have been going through the same pain and for now we have decided to go with approach #2.
Hope this helps.
We are building a rest service and we want to use OAauth 2 for authorization. The current draft (v2-16 from May 19th) describes four grant types. They are mechanisms or flows for obtaining authorization (an access token).
Authorization Code
Implicit Grant
Resource Owner Credentials
Client Credentials
It seems we need to support all four of them, since they serve different purposes. The first two (and possibly the last one) can be used from third-party apps that need access to the API. The authorization code is the standard way to authorize a web application that is lucky enough to reside on a secure server, while the implicit grant flow would be the choice for a client application that can’t quite keep its credentials confidential (e.g. mobile/desktop application, JavaScript client, etc.).
We want to use the third mechanism ourselves to provide a better user experience on mobile devices – instead of taking the user to a login dialog in a web browser and so on, the user will simply enter his or her username and password directly in the application and login.
We also want to use the Client Credentials grant type to obtain an access token that can be used to view public data, not associated with any user. In this case this is not so much authorization, but rather something similar to an API key that we use to give access only to applications that have registered with us, giving us an option to revoke access if needed.
So my questions are:
Do you think I have understood the purpose of the different grant types correctly?
How can you keep your client credentials confidential? In both the third and fourth case, we need to have the client id and client secret somewhere on the client, which doesn't sound like a good idea.
Even if you use the implicit grant type and you don’t expose your client secret, what stops another application from impersonating your app using the same authorization mechanism and your client id?
To summarize, we want to be able to use the client credentials and resource owner credentials flow from a client application. Both of these flows require you to store the client secret somehow, but the client is a mobile or JavaScript application, so these could easily be stolen.
I'm facing similar issues, and am also relatively new to OAuth. I've implemented "Resource Owner Password Credentials" in our API for our official mobile app to use -- the web flows just seem like they'd be so horrible to use on a mobile platform, and once the user installs an app and trusts that it's our official app, they should feel comfortable typing username/password directly into the app.
The problem is, as you point out, there is no way for my API server to securely verify the client_id of the app. If I include a client_secret in the app code/package, then it's exposed to anyone who installs the app, so requiring a client_secret wouldn't make the process any more secure. So basically, any other app can impersonate my app by copying the client_id.
Just to direct answers at each of your points:
I keep re-reading different drafts of the spec to see if anything's changed, and am focused mostly on the Resource Owner Password Credentials section, but I think you're correct on these. Client Credentials(4) I think could also be used by an in-house or third-party service that might need access to more than just "public" information, like maybe you have analytics or something that need to get information across all users.
I don't think you can keep anything confidential on the client.
Nothing stops someone else from using your client id. This is my issue too. Once your code leaves the server and is either installed as an app or is running as Javascript in a browser, you can't assume anything is secret.
For our website, we had a similar issue to what you describe with the Client Credentials flow. What I ended up doing is moving the authentication to the server side. The user can authenticate using our web app, but the OAuth token to our API is stored on the server side, and associated with the user's web session. All API requests that the Javascript code makes are actually AJAX calls to the web server. So the browser isn't directly authenticated with the API, but instead has an authenticated web session.
It seems like your use-case for Client Credentials is different, in that you're talking about third-party apps, and are only serving public data through this method. I think your concerns are valid (anyone can steal and use anyone else's API key), but if you only require a free registration to get an API key, I don't see why anyone would really want to steal one.
You could monitor/analyze the usage of each API key to try to detect abuse, at which point you could invalidate one API key and give the legitimate user a new one. This might be the best option, but it's in no way secure.
You could also use a Refresh Token-like scheme for this if you wanted to lock it up a bit tighter, although I don't know how much you would really gain. If you expired the Javascript-exposed api tokens once a day and required the third-party to do some sort of server-side refresh using a (secret) refresh token, then stolen api tokens would never be good for more than a day. Might encourage potential token thieves to just register instead. But sort of a pain for everyone else, so not sure if this is worth it.