what is phpmyid exactly?
can I use it for logging into yahoo mail?
which steps I must follow?
Well, basically OpenID is a way to authenticate yourself to various places (websites) by verifying your identity as the owner of a particular URL (say, a website of your own)
I can't understand it's explanation exactly.
OpenID is a way of using one ID for multiple sites. Think of it like using a Facebook login to register on multiple sites, just without the Facebook account.
The great thing about OpenID is that it's based on secure principles, and you only have to remember one password to identify yourself to any site that chooses to implement OpenID.
The problem, however, is that OpenID relies on OID providers. If you want to maintain your own identity, you're pretty much out of luck. You still have to hand over some of your identity to a third party who maintains your identity to serve it to any website which you authorize to use your identity to log you in.
PHPMyID allows you to essentially be your own identity provider. Instead of registering on one centralized provider to maintain your profile, you set up the script and run it on your own server. This way, you retain control of your own identity, while still using one login for any website that supports OpenID.
Note, of course, that PHPMyID is no longer developed.
phpmyid is a buggy, insecure and unmaintained openid implementation that you should not bother with. See this page for the juicy details.
Related
I have 2 sites:
SITE A - an asp.net site
SITE B - a php site
We have all the user information in an asp.net site (which is actually a Kentico site).
Now, there is a business requirement that users should be able to log-in with the same credentials in Site B. Ideally, we would need that users who log-in Site A, and navigate to Site B, the authentication would be automatic.
Is there a way to achieve this form of authentication. Or is it not possible?
This is not an authentication problem, but an authorization one. Once you have authenticated your user, in whichever way you want, with whichever technology you want, you probably will grant them some sort of token that you will then use to grant authorization to the different resources in your sites.
In your case you have two different technologies, which only means that you won't be able to use the out of the box asp.net or php session management, but all you need to do is have a common place to check that the session tokens are valid, they belong to a legitimate user and that user has permissions to access this resource.
If the above is trivial, sorry, maybe your question is more oriented to the sites being in two different domains, and therefore not being able to use a domain cookie to store the session information. is that the case?
The canonical solution to this is to use a protocol like OpenID. OpenID allows a website to ask a user to authenticate themselves using a different site, and then honour those credentials; using a protocol called "attribute Exchange", the authentication provider can provide additional data about the user.
OpenID is how StackExchange manages to log you in with your Google account (or whatever you're using), and how sites in the SO network recognize your identity without you logging in everywhere.
The benefit for OpenID is that it's a widely used protocol, so it's likely to be highly secure and well-tested; you don't risk weaving your own solution and accidentally exposing your users to security risks. It's well-documented, and widely supported.
There's an OpenID framework for .Net which allows you to create your own OpenID provider; it appears Kentico supports OpenID as an authentication mechanism. There are several OpenID libraries for PHP (Google is your friend here).
Exactly how you implement this depends on how your Kentico authentication works right now, but in principle it should be fairly easy to glue the Kentico user database to an OpenID provider you write; getting Kentico to use that for authentication appears to be a configuration setting. You'd have to re-write the PHP site to use OpenID; again, not clear how that currently works, but I can't imagine it would be harder than any other solution you might try.
I had a similar issue on a .net platform where I didn't have the option to put them on one subdomain. In that case you could pass the username and a token (that signified the user was already authenticated by site B) and perhaps the encrypted password to re-authenticate against an external DB, then redirect them to the site. In my case I needed to do this as I was redirecting to the corresponding site CMS for site admins.
We have an app hosted on our domain. All users are required to first log in through a POST form. Once login has happened, then form redirects to dashboard page on our site automatically.
Is it possible to allow some clients to host their own login forms (on their site), that POSTS to our app? Is cross-domain posting considered bad practise in any way? Are there any pitfalls to be aware of? And lastly, how is SSL taken care of given that our site always runs on HTTPS, but client sites may not? Can this be circumvented with an iframe?
What you are trying to reinvent is called openid.
What you need to do is provide a openid service, and then users can make there own login forms that connect to your open id server.
I have a great example of such a site: http://www.stackoverflow.com that uses google and others as openid service to log in, making there own login form.
What you're trying to do is generally referred to as Single Sign-On (SSO). This can be implemented using a variety of technologies.
The general idea is to separate the Service Provider (SP) (also sometimes called Resource Provider), which is what provides the actual service the user is going to use, from the Identity Provider (IdP), which is where the user's identity is verified.
The simplePHP library provides implementations for both IdP and SP authenticating layer using a number of SSO standards: SAML, Shibboleth (also SAML-based), OpenID, ...
Note that if you're using a standard, the IdP shouldn't need to be implemented using the same implementation as the one you've chosen for your service. It could be possible to have an IdP implemented in Java using the Shibboleth libraries and use it in conjunction with an SP that uses simplePHP, for example.
Which of these techniques you use will depend on the kind of information your require after authentication, for example if extra attributes are required, and how trust is managed between the IdPs and the SPs.
Typically, a simple OpenID system will be rather straightforward to integrate, from an SP point of view, but it will be quite limited in what it can assert about the user. In contrast, Shibboleth has a number of options to specify which SP can see which user attributes and what IdPs are meant to release or not, but it requires a more substantial infrastructure: this is typically done in a federation, where all the parties exchange a set of metadata configuration that comprises X.509 certificates they use to trust each others' assertions.
Since the authentication will happen outside your administrative boundaries, you can't really control how the users will have authenticated (unless this is part of a more formal agreement, such as in a Shibboleth federation). The OpenID provider could potentially let users authenticate over plain HTTP even if your service requires HTTPS. (This being said, most serious OpenID providers do it securely, and it's up to the user to pick one their trust anyway.)
Never embed the IdP page in your service: make the user go to a their IdP page instead. For an authentication system to be secure (as far as the user is concerned), it is essential that the user be able to see what they're typing their passwords in. By using an iframe, you would effectively hide the real site behind (and logos are easy to grab/forge). (The StackExchange OpenID provider has some problems in that respect.)
I'm writing an Android app that will require folks to identify themselves. We figured that the best course of action is to NOT have folks register with our server since practically everybody has an account somewhere else with a major service (Google, Twitter, Facebook, Yahoo! for example).
The REST API is being built around CakePHP. This in itself isn't a sticking point for what I need, but the issue is more on the Android app along with its communication to our API. Essentially what I'd like to see is a user with X number of devices having the ability to login to a service they already have access to.
This identity would then be known by our server as an identity for that user. My app would then need a way to tell our API that "I am John Doe from service example.com, and here's proof". The servers would also accept a new device for the same identity and tie it in to that user.
I am stuck on some issues here:
OpenID seems to be the way to go (though I'm not sure if Twitter supports OpenID). But how can I do OpenID from my device? I don't need somebody to point me to OpenID for Java. This is NOT 100% of the answer I am looking for. Where is the website going to redirect to?
What will the authentication piece be like between my webserver and Android app? I'm not logging in. I'm using an OpenID. Should I just take some/all of the OpenID information and pass it to the webserver for storage, and then pass it again to check against for every API call?
Twitter not only does OpenID, but they also have a dedicated page talking about what the flow is and what you need to store. Google has a similar page for their login. The OpenID login flows are (for the most part) OAuth2.
I'm trying to understand the use cases for which implementing oAuth as a service provider is the way to go. It seems that implementing an oAuth service is a lot of work, so I don't want to go through the trouble just to discover I was barking up the wrong tree. Any examples of such use cases to help me wrap my head around when to use or not use oAuth?
This question is related to another question I asked but they deserved to be separate questions. I provide detail on my specific use case here:
Implementing access with oAuth or other
OAuth is typically used when you want to provide a single point of authentication for multiple services, or if you want to integrate an application with an existing authentication service; e.g., if you wanted your users to log in with their Twitter account information.
In my experience, the only time I've had reason to implement an OAuth authentication service was because we had 3 very different applications running on different platforms (JBoss, LAMP, and ASP.NET) on different servers. To compensate for different databases and different technologies, we settled on an OAuth implementation and centralized authentication to one point. It also provided an excellent means of securing user information between servers; data is encrypted between OAuth Server and Client, making it harder to jeopardize.
It really depends on what you're trying to do. If you're just talking about one application, then OAuth is definitely too much too soon. If you're talking about a few applications that run on the same technologies, then you may or may not have to go with OAuth; you could just use the existing data store to authenticate with. If you're looking to scale out to multiple systems, or you're thinking of implementing a single sign-in type of service, then OAuth is definitely a consideration.
OAuth has a few things going for it:
1) OAuth is a fairly well known standard, which means there is quite a bit of information available about it, code libraries in a variety of languages and platforms, etc. This may be the most important aspect if you are trying to get widespread adoption of your site/service (ala Twitter, FB, etc)
2) OAuth has been reasonably validated from a security perspective so you don't have to worry (too much) whether it is conceptually sound. Your implementation of course is another matter...
3) As mentioned by others, OAuth is well suited for distributed/federated scenarios. This allows you to outsource the authentication responsibility (for example, Microsoft's Azure can do OAuth authentication on your behalf) and/or share credentials across multiple services.
Hope this helps!
Started with this question: OpenID. How do you logout
OK. So OpenID does not have single logout.
I can see the uses but there are some situations that worry me:
Single signon on is great for mobile devices and your personal computer.
You sign on once and probably never need to sign out again (just authenticating with new sites as you go).
But if I am on a public computer (airport, or even a work computer) this is a problem.
When I sign into a website using openID I am signing into two different places and that is not obvious. I sign-onto a website (stackoverflow for example using gmail account) but at the same time I have just signed into gmail (OpenID Provider).
When I sign out of stackoverflow I am still singed into gmail (OpenID Provider).
When I authenticate with gmail I don't want to login into gmail I just want to authenticate.
A hack around this is to have the logout flow log me out of gmail at the same time, but as noted on the last post, if I log out of stackoverflow I don't necessarily want to logout of gmail if I am at home.
So the question really is:
Is there a way to authenticate with these OpenID providers without logging on.
Because even sites like stack overflow, they do not log you out when you logout of the OpenID provider you authenticated with. If you have gmail account I can log in and out all day without affecting if stackoverflow is logged in.
If the protocol doesn't support it (and it doesn't) then there's nothing you can do here, aside from delete all your cookies once you're done, which would clear the cookie which logs you into your provider and the ones that log you into services.
As an aside an OpenID provider doesn't have to provide you with a persistent cookie, or even a session cookie which keeps you logged into your OpenID account, it could authenticate you once for itself, then sent the authentication token onwards. If you're worried about being logged into Gmail when you use OpenID then choose another OpenID provider.
But how is this a question?
People apparently fail to see the question in your question, so I repeat it here just for clarity (and with a question mark)
Is there a way to authenticate with these OpenID providers without logging on?
I believe that the answer to this question is "no" (as blowdart elaborates).
The short answer is yes, in practice, by choosing a reasonable OpenID provider.
The long answer is that this is a question about your OpenID provider, not OpenID itself.
OpenID only handles authentication. Session support (and related concepts such as logging in or out) is outside of the OpenID spec.
Your OpenID provider may keep a session for you (probably with a browser cookie). Any reasonable provider will not do this unless you indicate ("remember me when logging into stackoverflow.com").
The OpenID consumer (such as StackOverflow) may keep a session for you as well. There is nothing you can do about this, but this is true for any authentication scheme, whether 3rd party or direct.
Because the 3rd-party aspects of OpenID are well designed, it is easy to avoid logging in in practice, by choosing a reasonable provider, or better yet, by using a HTML page as your claimed identity, which delegates to a provider which you can change if you decide to switch.
OpenID doesn't specify if provider should create a login session for themselves but almost all of them do. So there is no option to just authenticate RP without leaving a session in OP.
If you really want to authenticate without leaving a session, you can do it with other protocols. Just about every OP provides a proprietary protocol to login with username/password. For example, Google has ClientAuth and AOL has directLogin. This is so called password anti-pattern. It creates some privacy concerns because you collect Google password on your site. I am not recommending it in anyway.