Authentication and authorization
This page has moved to docs.servicestack.net
Built into ServiceStack is an optional Authentication feature you can use to add Authentication to your services by providing web services to Authenticate existing users, Register new users as well Assign/UnAssign Roles to existing users (if you need them). It's highly pluggable and customizable where you can plug-in your own Auth logic, change the caching and session providers as well as what RDBMS is used to persist UserAuth data.
A minimal configuration needed to get Basic Authentication up and running is the following in AppHost.Config()
(derived from the AuthTests unit test):
public override void Configure(Container container)
{
Plugins.Add(new AuthFeature(() => new AuthUserSession(),
new IAuthProvider[] {
new BasicAuthProvider(), //Sign-in with HTTP Basic Auth
new CredentialsAuthProvider(), //HTML Form post of UserName/Password credentials
}));
Plugins.Add(new RegistrationFeature());
container.Register<ICacheClient>(new MemoryCacheClient());
var userRep = new InMemoryAuthRepository();
container.Register<IUserAuthRepository>(userRep);
//The IUserAuthRepository is used to store the user credentials etc.
//Implement this interface to adjust it to your app's data storage
}
The high-level overview below shows how all the different parts fit together and which parts are customizable:
From the overview we can see the built-in AuthProviders that are included:
-
Credentials - For authenticating with username/password credentials by posting to the
/auth/credentials
service - API Keys - Allowing users to authenticate with API Keys
- JWT Tokens - Allowing users to authenticate with JWT Tokens
- Basic Auth - Allowing users to authenticate with HTTP Basic Auth
- Digest Auth - Allowing users to authenticate with HTTP Digest Authentication
-
Custom Credentials - By inheriting CredentialsAuthProvider and providing your own Username/Password
TryAuthenticate
implementation - AspNetWindowsAuthProvider - Allowing users to authenticate with Windows Authentication
- Twitter OAuth - Allow users to Register and Authenticate with Twitter
- Facebook OAuth - Allow users to Register and Authenticate with Facebook
- GitHub OAuth - Allow users to Register and Authenticate with GitHub
- Yammer OAuth - Allow users to Register and Authenticate with Yammer
- Yandex OAuth - Allow users to Register and Authenticate with Yandex
- VK OAuth - Allow users to Register and Authenticate with VK
- Odnoklassni OAuth - Allow users to Register and Authenticate with Odnoklassni
The ServiceStack.Authentication.OAuth2 NuGet package provides OAuth2 Providers support to ServiceStack that includes:
- Instagram OAuth2 - Allow users to Register and Authenticate with Instagram OAuth2
- Google OAuth2 - Allow users to Register and Authenticate with Google OAuth2
- LinkedIn OAuth2 - Allow users to Register and Authenticate with LinkedIn OAuth2
- Microsoft Live OAuth2 - Allow users to Register and Authenticate with Microsoft Live OAuth2
The ServiceStack.Authentication.OpenId NuGet package provides OpenId Auth Providers support to ServiceStack that includes:
- Google OpenId - Allow users to Register and Authenticate with Google
- Yahoo OpenId - Allow users to Register and Authenticate with Yahoo
- MyOpenId - Allow users to Register and Authenticate with MyOpenId
- OpenId - Allow users to Register and Authenticate with any custom OpenId provider
The ApiKeyAuthProvider
provides an alternative method for allowing external 3rd Parties access to your protected Services without needing to specify a password.
The JwtAuthProvider
is our integrated stateless Auth solution for the popular JSON Web Tokens (JWT) industry standard.
- Azure Active Directory - Allow Custom App to login with Azure Active Directory
- ServiceStack.Authentication.IdentityServer - Integration with ASP.NET IdentityServer and provides OpenIDConnect / OAuth 2.0 Single Sign-On Authentication
Find more info about OpenId 2.0 providers on the wiki.
The OAuth providers below require you to register your application with them in order to get the ConsumerKey
and ConsumerSecret
required, at the urls below:
- Twitter dev.twitter.com/apps
- Facebook developers.facebook.com/apps
- Instagram instagram.com/developer/authentication
- Google OAuth2 code.google.com/apis/console/
- LinkedIn OAuth2 www.linkedin.com/secure/developer
- Microsoft Live OAuth2 account.live.com/developers/applications
- Yammer www.yammer.com/client_applications
- GitHub github.com/settings/applications/new
- Yandex oauth.yandex.ru/client/new
- VK vk.com/editapp?act=create
- Odnoklassniki www.odnoklassniki.ru/devaccess
AuthWebTests is a simple project that shows all Auth Providers configured and working in the same app. See the AppHost for an example of the code and the Web.config for an example of the configuration required to enable each Auth Provider.
Once you have the ConsumerKey
and ConsumerSecret
you need to configure it with your ServiceStack host, via Web.config, e.g:
<add key="oauth.twitter.RedirectUrl" value="http://yourhostname.com/"/>
<add key="oauth.twitter.CallbackUrl" value="http://yourhostname.com/auth/twitter"/>
<add key="oauth.twitter.ConsumerKey" value="3H1FHjGbA1N0n0aT5yApA"/>
<add key="oauth.twitter.ConsumerSecret" value="MLrZ0ujK6DwyjlRk2YLp6HwSdoBjtuqwXeHDQLv0Q"/>
Note: Each OAuth Config option fallbacks to the configuration without the provider name. This is useful for reducing repetitive configuration that's shared by all OAuth providers like the
RedirectUrl
orCallbackUrl
, e.g:
<add key="oauth.RedirectUrl" value="http://yourhostname.com/"/>
<add key="oauth.CallbackUrl" value="http://yourhostname.com/auth/{0}"/>
Or via configuration in code when you register the AuthFeature
in your AppHost, e.g:
Plugins.Add(new AuthFeature(() => new AuthUserSession(), new IAuthProvider[] {
new TwitterAuthProvider(appSettings) {
RedirectUrl = "http://yourhostname.com/",
CallbackUrl = "http://yourhostname.com/auth/twitter",
ConsumerKey = "3H1FHjGbA1N0n0aT5yApA",
ConsumerSecret = "MLrZ0ujK6DwyjlRk2YLp6HwSdoBjtuqwXeHDQLv0Q",
},
}));
Note: The Callback URL in each Application should match the CallbackUrl for your application which is typically: http://yourhostname.com/auth/{Provider}, e.g. http://yourhostname.com/auth/twitter for Twitter.
By default the CredentialsAuthProvider
and BasicAuthProvider
validate against users stored in the UserAuth repository. The registration service at /register
allow users to register new users with your service and stores them in your preferred IUserAuthRepository
provider (below). The SocialBootstrapApi uses this to allow new users (without Twitter/Facebook accounts) to register with the website.
A good starting place to create your own Auth provider that relies on username/password validation is to subclass CredentialsAuthProvider
and override the bool TryAuthenticate(service, username, password)
hook so you can add in your own implementation. If you want to make this available via BasicAuth as well you will also need to subclass BasicAuthProvider
with your own custom implementation.
UserAuth Persistence - the IUserAuthRepository
The Authentication module allows you to use your own persistence back-ends but for the most part you should be able to use one of the existing InMemory, Redis, OrmLite or MongoDB adapters. Use the OrmLite adapter if you want to store the Users Authentication information in any of the RDBMS's that OrmLite supports, which as of this writing includes Sql Server, Sqlite, MySql, PostgreSQL and Firebird.
-
OrmLite:
OrmLiteAuthRepository
in ServiceStack.Server -
Redis:
RedisAuthRepository
in ServiceStack -
In Memory:
InMemoryAuthRepository
in ServiceStack -
AWS DynamoDB:
DynamoDbAuthRepository
in ServiceStack.Aws -
Mongo DB:
MongoDBAuthRepository
in ServiceStack.Authentication.MongoDB -
Raven DB:
RavenUserAuthRepository
in ServiceStack.Authentication.RavenDB
Caching / Sessions - the ICacheClient
Once authenticated the AuthUserSession model is populated and stored in the Cache using one of ServiceStack's supported Caching providers. ServiceStack's Sessions simply uses the ICacheClient
API so any new provider added can be used for both Session and Caching options. Which currently include the following implementations:
-
In Memory:
MemoryCacheClient
in ServiceStack -
Redis:
RedisClient
,PooledRedisClientManager
orBasicRedisClientManager
in ServiceStack.Redis -
Memcached:
MemcachedClientCache
in ServiceStack.Caching.Memcached -
AWS DynamoDB:
DynamoDbCacheClient
in ServiceStack.Aws -
Azure:
AzureCacheClient
in ServiceStack.Caching.Azure The Auth Feature also allows you to specify your own customIUserAuthSession
type so you can attach additional metadata to your users session which will also get persisted and hydrated from the cache.
Note: If you're using Custom Sessions and have
JsConfig.ExcludeTypeInfo=true
, you need to explicitly enable it withJsConfig<TCustomSession>.IncludeTypeInfo=true
.
After authentication the client will receive a cookie with a session id, which is used to fetch the correct session from the ICacheClient
internally by ServiceStack. Thus, you can access the current session in a service:
public class SecuredService : Service
{
public object Get(Secured request)
{
IAuthSession session = this.GetSession();
return new SecuredResponse() { Test = "You're" + session.FirstName };
}
}
ServiceStack's Authentication, Caching and Session providers are completely new, clean, dependency-free testable APIs that doesn't rely on and is devoid of ASP.NET's existing membership, caching or session provider models.
To illustrate Authentication integration with ServiceStack, see the authentication-enabled live demos below:
-
HttpBenchmarks Application
- Step-by-Step Authentication Guide
- Twitter, Facebook, Google, LinkedIn and Credentials Auth
-
AWS Auth
- Twitter, Facebook, GitHub, Google, Yahoo, LinkedIn, and Credentials Auth
-
MVC and WebForms Example
- Twitter, Facebook, GitHub, Google, Yahoo, LinkedIn, VK, Credentials and Windows Auth
-
Chat
- Twitter and GitHub OAuth
-
SocialBootstrap Api
- Twitter, Facebook, Yahoo and Credentials Auth
The classes in ServiceStack have been designed to provide default behavior out the box (convention over configuration). They are also highly customizable. Both the default BasicAuthProvider and CredentialsAuthProvider (which it extends) can be extended, and their behavior overwritten. An example is below:
using ServiceStack;
using ServiceStack.Auth;
public class CustomCredentialsAuthProvider : CredentialsAuthProvider
{
public override bool TryAuthenticate(IServiceBase authService,
string userName, string password)
{
//Add here your custom auth logic (database calls etc)
//Return true if credentials are valid, otherwise false
}
public override IHttpResult OnAuthenticated(IServiceBase authService,
IAuthSession session, IAuthTokens tokens,
Dictionary<string, string> authInfo)
{
//Fill IAuthSession with data you want to retrieve in the app eg:
session.FirstName = "some_firstname_from_db";
//...
//Call base method to Save Session and fire Auth/Session callbacks:
return base.OnAuthenticated(authService, session, tokens, authInfo);
//Alternatively avoid built-in behavior and explicitly save session with
//authService.SaveSession(session, SessionExpiry);
//return null;
}
}
Then you need to register your custom credentials auth provider:
//Register all Authentication methods you want to enable for this web app.
Plugins.Add(new AuthFeature(() => new AuthUserSession(),
new IAuthProvider[] {
new CustomCredentialsAuthProvider(), //HTML Form post of User/Pass
}
));
By default the AuthFeature plugin automatically registers the following (overrideable) Service Routes:
new AuthFeature = {
ServiceRoutes = new Dictionary<Type, string[]> {
{ typeof(AuthService), new[]{"/auth", "/auth/{provider}"} },
{ typeof(AssignRolesService), new[]{"/assignroles"} },
{ typeof(UnAssignRolesService), new[]{"/unassignroles"} },
}
};
The AuthService
is registered at paths /auth
and /auth/{provider}
where the Provider maps to the IAuthProvider.Provider
property of the registered AuthProviders. The urls for clients authenticating against the built-in AuthProviders are:
-
/auth/credentials
- CredentialsAuthProvider -
/auth/apikey
- ApiKeyAuthProvider -
/auth/jwt
- JwtAuthProvider -
/auth/basic
- BasicAuthProvider -
/auth/twitter
- TwitterAuthProvider -
/auth/facebook
- FacebookAuthProvider -
/auth/instagram
- InstagramOAuth2Provider -
/auth/github
- GithubAuthProvider -
/auth/microsoftlive
- MicrosoftLiveOAuth2Provider -
/auth/yammer
- YammerAuthProvider -
/auth/googleopenid
- GoogleOpenIdOAuthProvider -
/auth/yahooopenid
- YahooOpenIdOAuthProvider -
/auth/myopenid
- MyOpenIdOAuthProvider -
/auth/openid
- OpenIdOAuthProvider (Any Custom OpenId provider) -
/auth/linkedin
- LinkedInOAuth2Provider -
/auth/googleoauth
- GoogleOAuth2Provider -
/auth/yandex
- YandexAuthProvider -
/auth/vkcom
- VkAuthProvider -
/auth/odnoklassniki
- OdnoklassnikiAuthProvider
You can do a GET or POST to /auth/logout
to logout the authenticated user or if you're using C# client you can logout with:
client.Post(new Authenticate { provider = "logout" });
Logging out will remove the Users Session from the Server and Session Cookies from the Client and redirect to the url in Authenticate.Continue, session.ReferrerUrl, 'Referer' HTTP Header or AuthProvider.CallbackUrl.
On the client you can use the C#/.NET Service Clients to easily consume your authenticated Services.
To authenticate using your CustomCredentialsAuthProvider
by POST'ing a Authenticate
Request, e.g:
var client = new JsonServiceClient(BaseUrl);
var authResponse = client.Post(new Authenticate {
provider = CredentialsAuthProvider.Name, //= credentials
UserName = "test@gmail.com",
Password = "p@55w0rd",
RememberMe = true,
});
If authentication was successful the Service Client client
instance will be populated with authenticated session cookies which then allows calling Authenticated services, e.g:
var response = client.Get(new GetActiveUserId());
If you've also registered the BasicAuthProvider
it will enable your Services to accept HTTP Basic Authentication which is built-in the Service Clients that you can populate on the Service Client with:
client.UserName = "test@gmail.com";
client.Password = "p@55w0rd";
Which will also let you access protected Services, e.g:
var response = client.Get(new GetActiveUserId());
Although behind-the-scenes it ends up making 2 requests, 1st request sends a normal request which will get rejected with a 401 Unauthorized
and if the Server indicates it has the BasicAuthProvider
enabled it will resend the request with the HTTP Basic Auth credentials.
You could instead save the latency of the additional auth challenge request by specifying the client should always send the Basic Auth with every request:
client.AlwaysSendBasicAuthHeader = true;
To Authenticate with your CustomCredentialsAuthProvider
(which inherits from CredentialsAuthProvider) you would POST:
POST
localhost:60339/auth/credentials?format=json
{
"UserName": "admin",
"Password": "test",
"RememberMe": true
}
When the client now tries to authenticate with the request above and the auth succeeded, the client will retrieve some cookies with a session id which identify the client on each Web Service call.
ServiceStack uses the Cache Provider which was registered in the IoC container:
//Register to use an In Memory Cache Provider (default)
container.Register<ICacheClient>(new MemoryCacheClient());
//Configure an alt. distributed persisted cache, E.g Redis:
//container.Register<IRedisClientsManager>(c =>
// new RedisManagerPool("localhost:6379"));
Tip: If you've got multiple servers which run the same ServiceStack service, you can use Redis to share the sessions between these servers.
Please look at SocialBootstrapApi to get a full example.
Of course you can also implement your own - custom - authentication mechanism. You aren't forced to use the built-in ServiceStack auth mechanism.
The [Authenticate]
Request Filter Attribute tells ServiceStack which Services needs authentication by adding it to your Service implementations, e.g:
[Authenticate]
public class SecuredService : Service
{
public object Get(Secured request)
{
IAuthSession session = this.GetSession();
return new SecuredResponse() { Test = "You're" + session.FirstName };
}
public object Put(Secured request)
{
return new SecuredResponse() { Test = "Valid!" };
}
public object Post(Secured request)
{
return new SecuredResponse() { Test = "Valid!" };
}
public object Delete(Secured request)
{
return new SecuredResponse() { Test = "Valid!" };
}
}
If you want, that authentication is only required for GET and PUT requests for example, you have to provide some extra parameters to the Authenticate
attribute.
[Authenticate(ApplyTo.Get | ApplyTo.Put)]
ServiceStack also includes a built-in permission based authorization mechanism. More details about how Roles and Permissions work is in this StackOverflow Answer.
Your request DTO can require specific permissions:
[Authenticate]
//All HTTP (GET, POST...) methods need "CanAccess"
[RequiredRole("Admin")]
[RequiredPermission("CanAccess")]
[RequiredPermission(ApplyTo.Put | ApplyTo.Post, "CanAdd")]
[RequiredPermission(ApplyTo.Delete, "AdminRights", "CanDelete")]
public class Secured
{
public bool Test { get; set; }
}
Now the client needs the permissions...
- "CanAccess" to make a GET request
- "CanAccess", "CanAdd" to make a PUT/POST request
- "CanAccess", "AdminRights" and "CanDelete" to make a DELETE request
If instead you want to allow access to users in ANY Role or Permission use:
[RequiresAnyRole("Admin","Member")]
[RequiresAnyRole(ApplyTo.Post, "Admin","Owner","Member")]
[RequiresAnyPermission(ApplyTo.Delete, "AdminRights", "CanDelete")]
public class Secured
{
public bool Test { get; set; }
}
Normally ServiceStack calls the method bool HasPermission(string permission)
in IAuthSession. This method checks if the list List<string> Permissions
in IAuthSession contains the required permission.
IAuthSession is stored in a cache client as explained above
You can fill this list in the method OnAuthenticated
you've overriden in the first part of this tutorial.
As with Authenticate
, you can mark services (instead of DTO) with RequiredPermission
attribute, too.
You can protect services by adding the [Authenticate]
attribute on either the Action:
class MyService : Service {
[Authenticate]
public object Get(Protected request) { ... }
}
The Request DTO
[Authenticate]
class Protected { ... }
Or the service implementation
[Authenticate]
class MyService : Service {
public object Get(Protected request) { ... }
}
Or by inheriting from a base class
[Authenticate]
class MyServiceBase : Service { ... }
class MyService : MyServiceBase {
public object Get(Protected request) { ... }
}
Otherwise you can use a global Request Filter if you wanted to restrict all requests any other way, e.g something like:
appHost.RequestFilters.Add((httpReq, httpResp, requestDto) =>
{
if (IsAProtectedPath(httpReq.PathInfo)) {
new AuthenticateAttribute().Execute(httpReq, httpResp, requestDto);
}
});
Different customization and extension points and strategies to extend the UserAuth tables with your own data are explained in this StackOverflow answer.
The default implementation of User Roles and Permissions on AuthUserSession shows how ServiceStack's [RequiredRole]
and [RequiredPermission]
Roles and Permission attributes are validated:
public virtual bool HasPermission(string permission)
{
var managesRoles = HostContext.TryResolve<IAuthRepository>() as IManageRoles;
if (managesRoles != null)
{
return managesRoles.HasPermission(this.UserAuthId, permission);
}
return this.Permissions != null && this.Permissions.Contains(permission);
}
public virtual bool HasRole(string role)
{
var managesRoles = HostContext.TryResolve<IAuthRepository>() as IManageRoles;
if (managesRoles != null)
{
return managesRoles.HasRole(this.UserAuthId, role);
}
return this.Roles != null && this.Roles.Contains(role);
}
These APIs are virtual
so they can be overridden in both your Custom AuthUserSession
. They default to looking at the Roles
and Permissions
collections stored on the Session. These collections are normally sourced from the AuthUserRepository
when persisting the UserAuth and UserAuthDetails POCO's and are used to populate the UserAuthSession
on successful Authentication. These collections can be further customized by AuthProviders which is what AspNetWindowsAuthProvider
does to add Authenticated WindowsAuth Roles.
As seen above Roles/Permissions can instead be managed by AuthProviders that implement IManageRoles
API which is what OrmLiteAuthProvider uses to look at distinct RDBMS tables to validate Roles/Permissions:
The IManageRoles API
can be implemented by any IAuthRepository
to provide an alternative strategy for querying and managing Users Roles and permissions.
This API is being used in the OrmLiteAuthRepository
to provide an alternative way to store
Roles and Permission in their own distinct table rather than being blobbed with the rest of the User Auth data.
You can enable this new behavior by specifying UseDistinctRoleTables=true
when registering the OrmLiteAuthRepository, e.g:
container.Register<IAuthRepository>(c =>
new OrmLiteAuthRepository(c.Resolve<IDbConnectionFactory>()) {
UseDistinctRoleTables = true,
});
When enabled, roles and permissions are persisted in the distinct UserAuthRole table instead of being blobbed on the UserAuth. The IAuthSession.HasRole()
and IAuthSession.HasPermission()
on the Users Session should be used to check if a User has a specified Role or Permission.
More examples of this are in ManageRolesTests.cs.
The CustomValidationFilter
on all AuthProviders lets you add post verification logic after a user has signed in with an OAuth provider and their OAuth metadata is retrieved. The filter lets you return a IHttpResult
to control what error response is returned, e.g:
new FacebookAuthProvider(appSettings) {
CustomValidationFilter = authCtx => CustomIsValid(authCtx)
? authCtx.Service.Redirect(authCtx.Session.ReferrerUrl
.AddHashParam("f","CustomErrorCode"))
: null,
}
Or could be used to redirect a network or users to a "Not Available in your Area" page with:
Plugins.Add(new AuthFeature(...,
new IAuthProvider[] {
new CredentialsAuthProvider {
CustomValidationFilter = authCtx =>
authCtx.Request.UserHostAddress.StartsWith("175.45.17")
? HttpResult.Redirect("http://host.com/are-not-available")
: null
}
}));
The UserName validation for all Auth Repositories are configurable at:
Plugins.Add(new AuthFeature(...){
ValidUserNameRegEx = new Regex(@"^(?=.{3,20}$)([A-Za-z0-9][._-]?)*$", RegexOptions.Compiled),
})
Instead of RegEx you can choose to validate using a Custom Predicate. The example below ensures UserNames don't include specific chars:
Plugins.Add(new AuthFeature(...){
IsValidUsernameFn = userName => userName.IndexOfAny(new[] { '@', '.', ' ' }) == -1
})
The new SaveExtendedUserInfo
property (enabled by default) on all OAuth providers let you control whether to save the extended OAuth metadata available (into UserAuthDetails.Items
) when logging in via OAuth.
The MaxLoginAttempts
feature lets you lock a User Account after multiple invalid login attempts, e.g:
Plugins.Add(new AuthFeature(...) {
MaxLoginAttempts = 5 // Lock user after 5 Invalid attempts
});
An IAuthMetadataProvider provides a way to customize the authInfo in all AuthProviders. It also allows overriding of how extended Auth metadata like profileUrl is returned.
public interface IAuthMetadataProvider
{
void AddMetadata(IAuthTokens tokens, Dictionary<string,string> authInfo);
string GetProfileUrl(IAuthSession authSession, string defaultUrl = null);
}
To override with a custom implementation, register
IAuthMetadataProvider
in the IOC
The LoadUserAuthFilter on AspNetWindowsAuthProvider
lets you retrieve more detailed information about Windows Authenticated users during Windows Auth Authentication by using the .NET's ActiveDirectory services, e.g:
//...
new AspNetWindowsAuthProvider(this) {
LoadUserAuthFilter = LoadUserAuthInfo
}
//...
public void LoadUserAuthInfo(AuthUserSession userSession,
IAuthTokens tokens, Dictionary<string, string> authInfo)
{
if (userSession == null) return;
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
var user = UserPrincipal.FindByIdentity(pc, userSession.UserAuthName);
tokens.DisplayName = user.DisplayName;
tokens.Email = user.EmailAddress;
tokens.FirstName = user.GivenName;
tokens.LastName = user.Surname;
tokens.FullName = (String.IsNullOrWhiteSpace(user.MiddleName))
? "{0} {1}".Fmt(user.GivenName, user.Surname)
: "{0} {1} {2}".Fmt(user.GivenName, user.MiddleName, user.Surname);
tokens.PhoneNumber = user.VoiceTelephoneNumber;
}
}
You can enable the CredentialsAuthProvider
to allow In Process requests to Authenticate without a Password with:
new CredentialsAuthProvider {
SkipPasswordVerificationForInProcessRequests = true,
}
When enabled this lets In Process Service Requests to login as a specified user without needing to provide their password.
For example this could be used to create an Intranet Restricted Admin-Only Service that lets you login as another user so you can debug their account without knowing their password with:
[RequiredRole("Admin")]
[Restrict(InternalOnly=true)]
public class ImpersonateUser
{
public string UserName { get; set; }
}
public object Any(ImpersonateUser request)
{
using (var service = base.ResolveService<AuthenticateService>()) //In Process
{
return service.Post(new Authenticate {
provider = AuthenticateService.CredentialsProvider,
UserName = request.UserName,
});
}
}
Your Services can use the new
Request.IsInProcessRequest()
to identify Services that were executed in-process.
The IHashProvider
used to generate and verify password hashes and salts in each UserAuth Repository can be overridden with:
container.Register<IHashProvider>(c =>
new SaltedHash(HashAlgorithm:new SHA256Managed(), theSaltLength:4));
The AuthFeature also regenerates new Session Cookies each time users login, this behavior can be disabled with:
Plugins.Add(new AuthFeature(...) {
GenerateNewSessionCookiesOnAuthentication = false
});
OAuth Providers can use ClientId
and ClientSecret
aliases instead of ConsumerKey
and ConsumerSecret
, e.g:
<appSettings>
<add key="oauth.twitter.ClientId" value="..." />
<add key="oauth.twitter.ClientSecret" value="..." />
</appSettings>
- Using IdentityServer 4 with ServiceStack and Angular by @estynedwards
Adding Facebook Authentication using ServiceStack by @markholdtHow to return JSV formatted collection types from SQL Server in OrmLite by AdamAndersonHow to migrate ASP.NET Membership users to ServiceStack by AdamAndersonAuthentication in Service Stack REST Services by @binaryforge- Building a ServiceStack OAuth2 resource server using DotNetOpenAuth by @dylanbeattie
- Declarative authorization in REST services in SharePoint with F# by @sergey_tihon
- Authenticate ServiceStack services against an Umbraco membership provider by Gavin Faux
Using OAuth with ArcGIS Online and ServiceStack by @davetimmins- LinkedIn Provider for ServiceStack Authentication by @binu_thayamkery
- A Step by Step guide to create a Custom IAuthProvider by @rngoodness
Simple API Key Authentication With ServiceStack by @rossipediaCORS BasicAuth on ServiceStack with custom authentication by @joeriks- Authenticating ServiceStack REST API using HMAC by @jokecamp
- ServiceStack Credentials Authentication and EasyHttp: Part 1, Part 2, Part 3 by [@chrissie1](
- Why ServiceStack?
- Important role of DTOs
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
-
Getting Started
-
Designing APIs
-
Reference
-
Clients
-
Formats
-
View Engines 4. Razor & Markdown Razor
-
Hosts
-
Security
-
Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in profiling
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Dump Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- MVC Integration
- ServiceStack Integration
- Embedded Native Desktop Apps
- Auto Batched Requests
- Versioning
- Multitenancy
-
Caching
-
HTTP Caching 1. CacheResponse Attribute 2. Cache Aware Clients
-
Auto Query
-
AutoQuery Data 1. AutoQuery Memory 2. AutoQuery Service 3. AutoQuery DynamoDB
-
Server Events
-
Service Gateway
-
Encrypted Messaging
-
Plugins
-
Tests
-
ServiceStackVS
-
Other Languages
-
Amazon Web Services
-
Deployment
-
Install 3rd Party Products
-
Use Cases
-
Performance
-
Other Products
-
Future