Is it possible to limit the users who can sign in with open id on my site. I have clients that I want to give access to a client area on my website. I don't want anyone with a open id to be able to login just my clients. Is this possible?
One way to do this would be to create a "sign up" form to validate the user. Part of the sign up process would be to associate your OpenID. You can then leave the newly created account in a "pending" mode to be approved by an admin. (note: if you have a different way of adding the clients, you would use that method.)
Basically you would create a profile for a user the same way you would in any other application, except you would replace the UserName / Password portion with OpenID.
OpenID is made for authentification, not for authorization. I am sure, you could make it work (*), however you must keep in mind that OpenID has not been made for this sort of task.
If you want to do it, you must probably restrict the set of allowed OpenID providers to prevent a malicious provider to hand faked/bogus identity URLs to your application (consumer).
(*) how, depends on where you want to enforce the restriction (web server, web framework, etc.)
Related
i'm using Cognito for user authentication on a site I'm working on for a client, and I need to add (if possible) a way for an admin (of the site) to login as a user. It's mainly used to see issues that the user is experiencing.
Do you know if there's a way to do that with Cognito, basically signing in as someone else if you have a specific code or belong to a specific group, or any other way?
Thanks
Not easily.
Effectively Cognito doesn't want you to be able to do this, as it opens no end of security issues within your application.
However, you can take control of the authorisation process by using Custom Authentication. By writing your own custom authentication, you can effectively allow user impersonation so long as the authenticating user can pass your authentication "tests".
I'd invite you to think hard about this method, however, as it does mean that you are now responsible for making sure no one else can use this backdoor.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
Does anyone have clues about how to do this? I'm basically trying to replace the strategy for "Connect With Google" from OpenID to OAuth. The challenge is identifying an old user (user on Google open ID) when a user signs in under the new OAuth scheme.
I have a working implementation which relies on email address as the primary key, as the open ID strategy captures that. The problem is, I don't want to ask for email in the OAuth flow. The ideal value is simply Google user ID, but the Open ID strategy doesn't seem to capture that.
So I have open ID tokens like https://www.google.com/accounts/o8/id?id=AfSCwGQ4PUaidXSQddJugXKLqU5V0MrXFhJM6UHybPw and trying to understand if I could get a Google ID from that.
UPDATE: I explained here how I ended up doing this migration - http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus
We don't have a strategy ready today that avoids the user seeing another approval page.
However, rather than attempt to do an OAuth1 based hybrid flow and have to add all that legacy code to your server, I'd suggest you simply correlate on email address and move to OAuth2 login. I'm assuming you're like the majority of sites that end up asking for email address because they usually want it for account recovery. Just make sure you get the email address from OpenId as one of the signed parameters.
Then use the userinfo.email scope and OAuth2 https://developers.google.com/accounts/docs/OAuth2Login and you should be able to migrate with less developer pain.
In addition, we're in the process of adding support for OpenIDConnect and it supports a parameter of login_hint so you'd add &login_hint=bob#gmail.com to your authorization URL and it will steer the approval to the right account. This is not documented right now but it may be useful for you to try it. The user's browser could be logged into Google with a number of accounts and you want to try to get the right one. Always check the email you get from the OAuth2 flow to make sure it matches since this is just a 'hint'.
Users will still have to re-authorize for OAuth2, but we have plans to skip this reauthorization in the future. The main point is to plan on using OAuth2 and we hope to deliver a seamless migration soon and you'll be on a supported protocol.
Google uses directed identifiers for OpenID that are unique per relying party and are explicitly designed to conceal any correlatable identifier for the user. So the short answer is, no there's no way to get a Google ID that corresponds with a given Google OpenID.
One option, however, might be to use Google's OpenID+OAuth Hybrid flow. This allows you to get an OAuth token as part of a normal OpenID flow, which could then be used to get the user's ID from the OAuth2 Login API, which you can then associate with their existing account. Once you've done that for all of your existing users, then switch to using the OAuth2 Login directly.
The trick, of course, with this approach is getting all of your users to login again so that you can send them through the new flow. That will come down to how long you're willing to wait to migrate accounts, and whether you're willing to prod existing users by emailing them and asking them to login again (similar to a forced password reset).
All I want is a persistent membership system and easy registration/login process for my several social applications.
I don't really need their e-mail addresses or personal information.
However, I don't want to convert my websites into an anonymous board or spamming area for bots, etc. and I don't want to force my visitors to login through their Facebook or Google accounts.
What do you recommend in this case?
Thanks.
You can't have it both ways. Either you want an anonymous site or you need some type of authentication/identification.
There are several easy options for authentication.
E-mail only. You can do authentication with e-mail only and cookies, no password. This isn't common and is often used in addition to passwords for high-security scenarios, but can be used without passwords for even simpler security. Basically have users log-in with their e-mail only. Then send them a confirmation mail and they click a link in the confirmation mail. When they click the link, store a permanent cookie and from then on they're authenticated. If they loose the cookie, they can repeat the process and authenticate again with the same e-mail address. No manual account creation, no passwords. It's really just as or even more secure than using a password. It's a little cumbersome though to get an e-mail to login, but hopefully cookies will not be lost. Several of my banking/credit card companies do this in addition to e-mail and the only time I notice is when I change computers.
E-mail/password. Don't downplay the usefulness and simplicity of a email/password authentication. Users are accustomed to id and it works fine. As long as you have it isolated to a single small form to create an account, it won't really get in the way.
OpenID. I believe all public website should support OpenID as an available authentication mechanism. For people and sites that use it, it's wonderful. Simple authentication and easy to use. Setup is painful for people that don't know what it is or how to use it, so I wouldn't recommend using OpenID only except for techie sites, but it's a great alternative.
I'd suggest you to use OpenID authentication on your website. This way, you need not to worry about the hassles of storing and retreiving user data on your server plus offer the facility to user to use thier OpenID login credentials for your website.
Kimd regards,
Dorcy
I'd like to create a piece of code that can be embedded on many different websites (widget).
Is there any way that my code can identify a user without them logging in? I.e, can I use any of the established identity mechanisms floating around the web to reliably identify them across instances of this widget?
I don't need to (nor should I be able to) tap into any information about this user, just identify them.
The websites will be heterogeneous; there's no guarantee that they will have any common aspects, so the widget code needs to be entirely self contained.
What you want to do is what cookies were invented for. But browsers have gotten wise to people being tracked without their permission, and now limit 3rd party cookies.
The Electronic Frontier Foundation recently put up a proof of concept for uniquely identifying a visitor based on attributes of their browser. It's uses things things like:
User-Agent string
http-accept values
timezone
screen resolution and color depth
the installed plugins
if cookies are enabled
It's not guaranteed to be unique, but my browser certainly is, and it will get you on your way to doing the bad things that people don't like.
OpenID is sort of a SSO for the whole internet, yet they still have to sign in to OpenID. Other than that, I can't think of a solution.
I would suggest Open-ID rather than some workaround like this, but if you don't like that solution you might consider something like this:
You can use a cookie from a single domain, then use that domain to redirect to the correct site adding user-id as a parameter or part of the URL-path
For instance a link to add a personal widget on the foo.com -site, could look something like:
http://bar.com/addwidget1?backtoo=http://foo.com/main/
bar.com would own the cookie, change the user preferences and then add user-id to the back-link before re-directing:
foo.com/user-id/
Issues with this approach includes
You need to rewrite every page dynamicly with the user-id.
It's a bit clumsy I think
You can't fully take advantage of web-caches around the net.
The user might loose their cookie.
Benefits
No login
Since you redirect a lot you get stats on the users movement across your sites.
Sounds like you want to implement a Single Sign On framework. Basically when you first see the user, if you don't know them, you redirect them to the single sign on server. Wich authenticates them and redirects them back to you with a authentication token. You verify the authentication token with a web service call to the SSO server. Ff it is valid then you mark that user as signed on.
EDIT
So thinking about it more and reading tovare's answer and your comments. Why not create some javascript code that works like an google ads? You put the javascript on the page and it does an a request to your central tracking server using a dynamic iframe.
Have your tracking server return an image tag with src of the unique id (its own session id) embedded.
<img src=contentserver.com/track.php?id=12345668>
The content server has a server side script (track.php above) that maps its local session id to the unique id received from the tracking server.
The unique id stays the same across all sites.
Edit2
Instead of using an image, use the javascript trick. The content server just requests a javascript file from the tracking server. but the file is a dynamic one generated on the server side. it returns a generated javascript function called unique_id() it returns the unique id from the tracking server. Call the track.php using ajax to determine if this is a unique user.
Use OpenID, or a simplified variant, with your own site as the identity provider. Redirect the user to your identifier site which sets or checks a cookie, then redirect the user back with the user's identity, which was indicated by the cookie, added as a URL argument.
Your identifier site can be an OpenID identity provider which doesn't require any user interaction to authenticate. The sites which receive this identity are probably not OpenID consumers, since they don't offer the user a choice of providers. You can probably do away with some of the signing required by OpenID if your cookie and identifier are signed.
Facebook provides something similar; a site can find the Facebook identity of a user (assuming the user has one) without any action on the user's part.