I'm setting up an OpenID provider using DotNetOpenAuth and I'm stuck.
It seems that OpenID requires that the user provides his OpenID URL first, and then the consumer would redirect him to the provider, giving the URL as a parameter (checkid_setup mode).
But with google, and some other providers, it works differently. You are just redirected to a generic page where you would either sign in, or select one of the accounts you're already logged in with. Or just redirected back if you're logged in with a single account.
Is this somehow related to the checkid_immediate mode? If so, please give me a link to an article explaining how that works.
The difference in behavior you're seeing is orthogonal to the checkid_setup vs. checkid_immediate modes that you're noticing.
If the user types in his own OpenID, that's called a Claimed Identifier. If instead the user just clicks (or types) his provider (e.g. Google in your example), that's called an OP Identifier.
For instance, if you type in https://www.google.com/accounts/o8/id into the OpenID box, you'll see the behavior you're describing, in that Google will assist the user in logging into your web site, whoever that user is.
So at this point you have a few options:
If your site is based on ASP.NET web forms, you can use the OpenIdButton control, typing in the https://www.google.com/accounts/o8/id identifier into the appropriate property, and the user can then click that button to simply log in using their Google account.
If you're using MVC (or using web forms but want to do this programmatically) you can call OpenIdRelyingParty.CreateRequest("https://www.google.com/accounts/o8/id") and redirect the user with the result to Google.
Either way, if the user is already logged into Google, they won't need to log into Google. And if the user has already told Google that they approve logging into your web site, then they won't see Google at all during this login process.
