-
Notifications
You must be signed in to change notification settings - Fork 0
OpenId
.
#OpenId 2.0 Authentication Support
Contained in the ServiceStack.Authentication.OpenId NuGet package is ServiceStack's support of OpenId 2.0 Authentication. This allows ServiceStack-enabled ASP.NET / MVC sites and web services to authenticate and accept registration from any OpenId 2.0 Authentication provider. Like most .NET OpenId libraries, we leverage the de-facto and excellent DotNetOpenAuth library to enable our OpenId support.
PM> Install-Package ServiceStack.Authentication.OpenId
As you might expect adding OpenId support works seamlessly with ServiceStack's existing Auth Providers where you can enable support for any Specific OpenId 2.0 provider with just 1-line of registration each. Below is the example taken from SocialBootstrapApi's AppHost showing how to extend their existing Auth Providers with new OpenId 2.0 options:
var appSettings = new AppSettings(); //Access Web.Config AppSettings
Plugins.Add(new AuthFeature(() => new CustomUserSession(),
//Add all the Auth Providers you want to allow registration with
new IAuthProvider[] {
//Existing Auth Providers
new CredentialsAuthProvider(), //HTML Form post of UserName/Password credentials
new TwitterAuthProvider(appSettings), //Sign-in with Twitter
new FacebookAuthProvider(appSettings), //Sign-in with Facebook
new DigestAuthProvider(appSettings), //Sign-in with Digest Auth
new BasicAuthProvider(), //Sign-in with Basic Auth
//Register new OpenId providers you want to allow authentication with
new GoogleOpenIdOAuthProvider(appSettings), //Sign-in with Goolge OpenId
new YahooOpenIdOAuthProvider(appSettings), //Sign-in with Yahoo OpenId
new OpenIdOAuthProvider(appSettings), //Sign-in with any Custom OpenId Provider
}));
Creating a custom OpenId provider is trivially done by just inheriting from OpenIdOAuthProvider
and providing a unique Id and Auth Realm Url for the provider. This is the source code for GoogleOpenIdOAuthProvider:
public class GoogleOpenIdOAuthProvider : OpenIdOAuthProvider {
public const string Name = "GoogleOpenId";
public static string Realm = "https://www.google.com/accounts/o8/id";
public GoogleOpenIdOAuthProvider(IResourceManager appSettings)
: base(appSettings, Name, Realm) { }
}
With just GoogleOpenIdOAuthProvider
class and it's registration above we can now enable authentication for our websites by just adding a HTML Form to POST to the /auth/{AuthProviderName}
AuthService, e.g:
<form action="/api/auth/googleopenid" method="POST">
<input type="image" src="/Content/img/sign-in-with-google.png" alt="Sign in with Google">
</form>
Any other custom OpenId provider can be added in the same way, here is the HTML Form for Yahoo OpenId:
<form action="/api/auth/yahooopenid" method="POST">
<input type="image" src="/Content/img/sign-in-with-yahoo.png" alt="Sign in with Yahoo!">
</form>
Finally you can allow registration of any other OpenId 2.0 provider at run-time by including their Url in the OpenIdUrl Form POST variable, e.g:
<form action="/api/auth/openid" method="POST">
<input type="text" name="OpenIdUrl" value="http://myopenid.com" />
<input type="submit" class="btn" value="Sign In"/>
</form>
The above sample markup from the Bootstrap Api project Index.cshtml page, which when rendered looks like:
For a live demo of ServiceStack's Auth Providers in action check out the MVC + ServiceStack enabled Bootstrap API project.
One of the benefits of using ServiceStack's Auth Providers is that it allows a single user to login via multiple Auth Providers and it takes care of merging authentication and registration info from multiple Authentication sources into the same UserAuth Account. It also automatically maintains updates of users latest registration information on each login and their session is automatically populated with all of their previously authenticated providers, e.g. If a user logs in the 2nd time with Facebook, their session is also populated with their earlier Twitter account information.
- Why ServiceStack?
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
- Getting Started
- Reference
- Clients
- Formats
- View Engines 4. Razor & Markdown Razor
- Hosts
- Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in caching options
- Built-in profiling
- Messaging and Redis
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- Plugins
- Tests
- Other Languages
- Use Cases
- Performance
- How To
- Future