auth0 / auth0.net

.NET client for the Auth0 Authentication & Management APIs.

📚 Documentation - 🚀 Getting Started - 💻 API Reference - 💬 Feedback

Documentation

• Docs site - explore our docs site and learn more about Auth0.

Getting started

Requirements

This library supports .NET Standard 2.0 and .NET Framework 4.5.2 as well as later versions of both.

Management API

Installation

Install-Package Auth0.ManagementApi

Usage

Generate a token for the API calls you wish to make (see Access Tokens for the Management API). Create an instance of the ManagementApiClient class with the token and the API URL of your Auth0 instance:

var client = new ManagementApiClient("your token", new Uri("https://YOUR_AUTH0_DOMAIN/api/v2"));

The API calls are divided into groups which correlate to the Management API documentation. For example all Connection related methods can be found under the ManagementApiClient.Connections property. So to get a list of all database (Auth0) connections, you can make the following API call:

await client.Connections.GetAllAsync("auth0");

Authentication API

Installation

Install-Package Auth0.AuthenticationApi

Usage

To use the Authentication API, create a new instance of the AuthenticationApiClient class, passing in the URL of your Auth0 instance, e.g.:

var client = new AuthenticationApiClient(new Uri("https://YOUR_AUTH0_DOMAIN"));

Authentication

This library contains URL Builders which will assist you with constructing an authentication URL, but does not actually handle the authentication/authorization flow for you. It is suggested that you refer to the Quickstart tutorials for guidance on how to implement authentication for your specific platform.

Important note on state validation: If you choose to use the AuthorizationUrlBuilder to construct the authorization URL and implement a login flow callback yourself, it is important to generate and store a state value (using WithState) and validate it in your callback URL before exchanging the authorization code for the tokens.

Feedback

Contributing

We appreciate feedback and contribution to this repo! Before you get started, please see the following:

• Auth0's general contribution guidelines
• Auth0's code of conduct guidelines

Raise an issue

To provide feedback or report a bug, please raise an issue on our issue tracker.

Vulnerability Reporting

Please do not report security vulnerabilities on the public GitHub issue tracker. The Responsible Disclosure Program details the procedure for disclosing security issues.

---

Auth0 is an easy to implement, adaptable authentication and authorization platform. To learn more checkout Why Auth0?

This project is licensed under the MIT license. See the LICENSE file for more info.

auth0.net's Issues

Support calling the /user/password endpoint with an email address instead of an id

In the scenario where we have a Google account (primary) which has a linked database account we cant use the /api/users/user_id/password endpoint.

For those scenarios we want to pass the email address in the body and use the following endpoint: https://auth0.com/docs/api#!#put--api-users--email--password

Support the "scope" option when calling /delegation.

The /delegation api (https://docs.auth0.com/auth-api#post--delegation) supports the "scope" option to indicate the type of id token you are looking for.
Right now the GetDelegationToken() method in the API is not giving any way of providing this option.

        /// <summary>
        /// Gets a delegation token.
        /// </summary>
        /// <param name="token">The current access token.</param>
        /// <param name="targetClientId">The client id of the target application.</param>
        /// <returns>An instance of DelegationTokenResult containing the delegation token id.</returns>
        public DelegationTokenResult GetDelegationToken(string token, string targetClientId)

Expose rate limits

Need to expose the rate limits to the user.

Look into approach similar to what octokit.net is proposing: octokit/octokit.net#504

XML docs for ResourceServer class

Need some assistance with proper documentation of this class:

public class ResourceServer
{
    [JsonProperty("identifier")]
    public string Identifier { get; set; }

    [JsonProperty("scopes")]
    public string[] Scopes { get; set; }
}

https://github.com/auth0/auth0.net/blob/v2/src/Auth0.Core/ResourceServer.cs

This is returned with the Client API calls

token endpoint does not return refresh_token

Need to update https://github.com/auth0/auth0.net/blob/master/src/Auth0.AuthenticationApi/Models/AccessToken.cs to deserialize refresh token

Change docs output folder path in s3

To match with the docs structure make the folder path:

libraries/auth0.net/{version}/ instead of sdks/auth0.net/{version}

Also, delete the old files afterward.

Configure build and deployment of Release versions

CI is set up on AppVeyor to create CI builds and publish Nuget packages to AppVeyor hosted feed. This needs to be expanded for release versions to publish to the official Nuget feed.

Some thoughts:

1. Should this be handled on different branches? Probably...
2. Do we really want to publish automatically to Nuget? One thing that comes to mind is that the project consists of 3 packages, Core, Auth API and Management API. If we publish automatically it means that we will always publish all 3 packages, regardless of whether that particular package has actually changed...

Users.DeleteAsyc call is risky!

If you accidentally pass null or an empty string to the Users.DeleteAsync method it will delete all of your users... I can't even see this mentioned in the documentation (https://auth0.com/docs/api/management/v2#!/Users/delete_users_by_id) and it took me more than a little by surprise.

Generate docs which can be integrated into website

All the classes are documented using XML documentation comments. We need to ensure that proper documentation is generated from this in a format which can be integrated into the main Auth0 developer website.

Missing fields when creating users

I've been looking through the code for creating users, and I've noticed an inconsistency with how you can create users on API v2 and the client library. The API supports adding a given_name, family_name, and name, but the Users client doesn't.

I'm aware the first three are on the API documentation, but they are allowable when using the API explorer. Is this something that's going to disappear off the API, hence it's exclusion from the users client?

Encoding issue when username has "+"

If string username has a "+" in it, the NestSharp Library method ParameterType.GetOrPost url encodes the "+" as %2B

It would appear that /oauth/ro converts %2B to single spaces ' ' in the username of the account created.

/oauth/ro has no problem creating accounts with usernames containing "+" signs... it's the url encoding of the username that causes the issue.

You can find the code here: https://github.com/auth0/auth0.net/blob/master/Auth0.Net/Client.cs

Incorrect _id field being used in SignupUserResponse

Here's a sample response from POST /dbconnections/signup:

{
  "_id": "573cea9ce0a882283e15f984",
  "email_verified": false,
  "email": "[email protected]"
}

However SignupUserResponse exposes the field id, which is never returned.

Allow sending arbitrary parameters to all Auth endpoints

we need to make sure that all authentication endpoints allow you to send arbitrary values to Auth0. eg, when I authenticate I need to specify foo=bar because I might need this in a rule for something.

Breadcrumbs on docs should be changed

The breadcumbs should be rooted with Documentation.

Documentation > Auth0.net SDK > then subpages

Documenation should point to /docs the Auth0.NET SDK should point to the relative root of the generated site

Add integration tests for PR 106

#106

Client.ExchangeAuthorizationCodePerAccessToken throws OAuthException in .NET 3.5

For whatever reason this code runs fine in .NET 4.5, but when using the Auth0.Net library in a .NET 3.5 project, the following exception is thrown when you call the ExchangeAuthorizationCodePerAccessToken method of the Client object (i.e. in your LoginCallback.ashx.cs):

OAuthException: Invalid authorization code

The error is being thrown from this line of code in the ExchangeAuthorizationCodePerAccessToken method, which means its coming from the underlying RestSharp library.

Auth0.Net is running a against an older version of RestSharp (v105.0.1 from Nov 13, 2014). They've made some bug fixes since then that probably fix this issue.

throw a nicer error when the configuration is wrong

right now is throwing an object reference exception

Add search across all connections

https://auth0.com/docs/api#!#get--api-users-search--criteria-

Repo needs a "V2" milestone for issues

Would be nice if collaborators could tag issues with "v2" and statuses like "bug", "feature request", etc.

better error handling when returning errors (in particular 402)

Currently it fails on the JSON serializer. We should handle those things more gracefuly

Add log endpoints

https://auth0.com/docs/api/v2#!/Logs/get_logs

Header and footer on docs

Header:
https://github.com/auth0/web-header

Footer should be the same as on https://auth0.com/docs

Style guide:
https://styleguide.auth0.com/

readme.md is not even working!

running the following code but getting exception: An unhandled exception of type 'System.NullReferenceException' occurred in Auth0.dll
Additional information: Object reference not set to an instance of an object.

var client = new Auth0.Client(
clientID: "........................",
clientSecret: "........................",
domain: "somedomain.auth0.com"
);

        var conn = client.GetConnections(); // this is where the null exception thrown! 

all clientID and clientsecret supplied are 100% correct. any ideas?

client_metadata is not available in the Client Object

The C# Client object does not expose a property for the client_metadata list.

Users should not be forced to provide clientSecret to do an active login.

The LoginUser method (https://github.com/auth0/auth0.net/blob/master/Auth0.Net/Client.cs#L493) is an instance method of the Client class, and thus requires the user to provide a clientSecret to create the client instance.
However, the active login endpoint (https://docs.auth0.com/auth-api#!#post--oauth-ro) does not require a clientSecret or token, so an user should be able to reach it providing only a clientId.
I'm to blame for the previous code :). Any ideas on how to fix it? A possibility might be to replace it with a (or add a new ) static method, that takes the clientId as a parameter.

ApiException constructor

The Auth0.Core.Exceptions.ApiException constructor that accepts just an HttpStatusCode does not set the StatusCode property.

Expand Tenants endpoint

The current wrappers for the Tenants API only supports the GET and PATCH operations. There does seem to be more operations available which is not currently documented (e.g. POST). This needs to be expanded to include all the other available endpoints.

Create Auth URL builder for second Auth URL

https://github.com/auth0-customers/api-authn-authz/blob/master/user-consent/calendarapp-implicit-jquery/server.js#L27

More detail to follow once I have more clarity on what this URL must do...

index.md in docs has absolute links

All links should be relative as the site will be hosted on a subfolder on auth0.com/docs

Add support to Link / Unlink accounts through Auth API

https://auth0.com/docs/auth-api#!#get--link

.net core

Will this work as is on .net core?

Social connections are reported as "not enabled", but on app.auth0.com, they are enabled

I followed the documentation (https://docs.auth0.com/mvc-tutorial), and additionally enabled a windows live id. Using the developer ids and secrets, the connections "google-oauth2" and "windowslive" arrive with Enabled = false when calling client.GetSocialConnections()

If I register the relevant OpenAuthClient's anyways, authentication using them works as expected.

I observed the same behaviour after I switched to "real" client ids and secrets in both connections on the auth0 service.

Add support for impersonation in Auth API

https://auth0.com/docs/auth-api#!#post--users--user_id--impersonate

Add support for the verification_ticket endpoint

When sending out custom verification emails (eg: I generate my own mail and send it out with SendGrid) we need a way to have the email address verified in Auth0. The API exposes the verification_ticket endpoint which generates an url that can confirm the email address. This endpoint is not available in the .NET SDK.

Docs: https://auth0.com/docs/api#!#post--api-users--user_id--verification_ticket

Incorrect target

I'm having a problem installing this library using Paket, please see this issue here:

fsprojects/Paket#1645

It looks like the target is incorrect, could you confirm?

Async methods

I now I'm a little late to the discussion on design (#45), but shouldn't async methods be named "xxxAsync()" if there is ever any hope of adding sync versions?
Even if sync versions are not in the roadmap any time soon, the conventions in .Net state that async methods should have the "Async" suffix. HttpClient, for example, an async only class, has all of its methods utilizing the prefix (https://msdn.microsoft.com/en-us/library/system.net.http.httpclient%28v=vs.118%29.aspx).

Auth0 get user throws missing authentication excpetion

I get below exception all of sudden in production environment..

https://auth0.com/docs/api/management/v2

as this link says token never expire.. what is wrong i am not able to understand.

Auth0.Core.Exceptions.ApiException: Missing authentication
at Auth0.Core.Http.ApiConnection.d__17.MoveNext() in C:\Development\auth0\auth0.net\src\Auth0.ManagementApi\Core\Http\ApiConnection.cs:line 301
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Auth0.Core.Http.ApiConnection.d__121.MoveNext() in C:\Development\auth0\auth0.net\src\Auth0.ManagementApi\Core\Http\ApiConnection.cs:line 160 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Auth0.Core.Http.ApiConnection.<GetAsync>d__91.MoveNext() in C:\Development\auth0\auth0.net\src\Auth0.ManagementApi\Core\Http\ApiConnection.cs:line 0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Aditro.Framework.Azure.Auth0Authentication.Auth0API.Auth0ApiClient.d__6.MoveNext() in C:\BuildAgent\work\770b00a853669c68\Framework\Aditro.Framework.Azure\Auth0Authentication\Auth0API\Auth0ApiClient.cs:line 40
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Aditro.Framework.Azure.Auth0Authentication.Auth0API.Auth0UserManager.d__2.MoveNext() in C:\BuildAgent\work\770b00a853669c68\Framework\Aditro.Framework.Azure\Auth0Authentication\Auth0API\Auth0UserManager.cs:line 18

Jobs test breaks build

Code is correct. Should investigate why this message occurs...

Update client for v2 of the API

The client currently consumes v1 of the api. It should be updated to support v2.

metadata on user appears to not be saving correctly

See https://ask.auth0.com/t/how-to-push-claims-to-users-profile-on-auth0-from-asp-net-5-mvc-6/2424/7

Maintaining backwards compatibility in V2

I had a brief look into maintaining backwards compatibility with V1 of the .NET Client when doing V2, but in the 30 minutes I spent I found a number of issues. Here are some of them:

• Right now the Client class is used for the API client, and there seems to be no classes to represent an actual Client as described in the API (https://auth0.com/docs/api/v2#!/Clients/get_clients). So I would like to change the Client class to ApiClient or Auth0Client or something like that, so we can use Client to represent an actual client.
• Send verification email is not available in V2, so needs to be removed.
• The updating of user metadata, password and email has been consolidated into the PATCH request on the users resource, so it can really be removed.
• When creating a connection, it seems the concept of a provisioning ticket has been removed.
• Getting users by connection is not available anymore.

Spending more time and going into more detail, I can probably find some more issues, so my question is:

How important is it to maintain backwards compatibility?

We can attempt to do it as far as possible, but in a number of cases it is going to be basically impossible. Would it therefore not be better to make a clean break while we have the chance?

The big concern would be for people using the Nuget package and upgrading. Their code is going to break horribly. We can perhaps create new, separate Nuget package for V2 to make it more clear that it is a completely new version?

Also, the coverage of the existing API is not too great. It seems many endpoints such as /clients, /device-credentials, /rules, /blacklists etc is not covered. When we start adding these, the number of methods of the base Client class (or ApiClient in new version) is going to be long.

So I want to propose another change as far as this is concerned. I want to propose a style similar to what the GitHub people did for the Octokit.net library (https://github.com/octokit/octokit.net)

They are basically grouping the related methods together under sub-clients which make it much easier to find methods you are looking for. Here is the basic definition of their IGitHubClient interface:

public interface IGitHubClient
    {
        IConnection Connection { get; }

        IAuthorizationsClient Authorization { get; }

        IActivitiesClient Activity { get; }

        IIssuesClient Issue { get; }

        IMiscellaneousClient Miscellaneous { get; }

        IOauthClient Oauth { get; }

        IOrganizationsClient Organization { get; }

        IPullRequestsClient PullRequest { get; }

        IRepositoriesClient Repository { get; }

        IGistsClient Gist { get; }

        IReleasesClient Release { get; }

        ISshKeysClient SshKey { get; }

        IUsersClient User { get; }

        INotificationsClient Notification { get; }

        IGitDatabaseClient GitDatabase { get; }

        ISearchClient Search { get; }
    }

So if we can do something similar it would group all the related methods together nicely and line up exactly with your API documentation. So if a user want to get all clients, they would type something like:

var apiClient = new ApiClient(....);
var clients = apiClient.Client.GetAll();

or if they want to create a user, they can write something similar to this:

var client = new ApiClient(...);
var user = new NewUser
{
   Connection = "....",
   Email = "....",
   // etc....
}
apiClient.Users.Create(user);

Obviously this new layout is also going to break backward compatibility horribly, but I think the final result will be better.

Would love to hear your feedback on this.

target .net 4?

Think you can have a target of .net 4?

How to watch the auth.IsAuthenticated property in AngularJS

Hi.. is there a way to watch the auth.IsAuthenticated property in AngularJS ?

   $scope.$watch(auth.isAuthenticated, function (value, oldValue) {
        alert(value);
    });

i have been trying to do the above code but the alert never been called and getting error:

$digest already in progress

Provide access to token endpoint

Provide access to the token endpoint (/token) to allow user to exchange OAuth code issued during OAuth authentication for an access token

https://github.com/auth0/auth0-aspnet-owin/blob/master/Auth0.Owin/Auth0AuthenticationHandler.cs#L22

IUserClient.GetAll not working when using the includeTotals flag.

It seems as if the response can't be deserialized to a type of IList.

V2 API Issue: Inconsistent object property naming

I'm creating this issue to track Auth0's exposed API members that do not appear to adhere to the naming convention of property names in all lowercase with a space separating words.

V2 API:

• user.identity.isSocial

Rules API:

• user.clientID
• context.clientID
• context.clientName
• context.connectionStrategy
• context.samlConfiguration
• context.jwtConfiguration
• context.stats.loginsCount
• context.request.userAgent
• context.request.geoip

I will edit this list with more items as I find them. I believe the desired result would be to modify these objects to confirm to internal conventions. If v2 is "official", then it may be best to wait for v3.

Blocked property not available when getting users

The blocked property should be available for reading when returning a list of users or a single user.

https://auth0.com/docs/api/v2#!/Users/get_users

Allow management of resource servers

curl -XPOST 'https://AUTH0_DOMAIN/api/v2/resource-servers' -H "Authorization: Bearer AUTH0_API2_TOKEN" -H "Content-Type: application/json" -d '{
  "identifier": "urn:organizer-api",
  "scopes": [
      { "value": "contacts", "description": "Manage your contacts" },
      { "value": "appointments", "description": "Manage your appointments" },
      { "value": "tasks", "description": "Manage your tasks" }
  ]
}'

License file wrong name

License should be called LICENSE instead of LICENSE.txt

Handle extra data returned from user profiles

Auth0's APIs don't presently have a way to delineate information that has been "normalized" from the rest of the properties returned from specific login providers. This means that the User payload from a Google login is vastly different from the User payload for a LinkedIn login.

This is going to create a problem for the .NET API, as the present V2 techniques will not make that data available to the developer; whatever properties are not mapped to an object will be ignored, and the raw payload will not be available either, so the end user won't be able to take advantage of the data (and to some developers monitoring HTTP requests, it may appear to them to be an error.

There are several options for handling this, and feel free to suggest others.

1. Change the way the results are processed on Auth0's servers, so that non-normalized profile properties are dumped in a different bucket, similar to the way app_metadata and user_metadata are presently handled. (This is the best option, because it will provide the most consistent experience to ALL Auth0 users.)
2. Leverage built-in PortableRest methods of getting the serialization result AND the raw request to load up a JObject with the raw result after the User object has been de-serialized. Then, use a LINQ query to get all non-normalized properties and dump them to a dynamic object on User called "ProviderUserData" (or something like that).
3. Same as 2, but try to serialize the remaining properties into provider-specific objects (Like "FacebookProviderUserData")
4. Leverage some of the built-in stuff in JSON.NET to plug some variation of Option 2 or Option 3 into its deserialization process, so that calls to the User APIs return either

• provider-specific User objects, like FacebookUser or GoogleUser, or
• regular User objects with strongly-typed provider-specific metadata objects.

I personally prefer strongly-types objects to something that could more easily fail at runtime. I'm assuming the Auth0 API can't return XML, so either parsing the payload manually or using JSON.NET Converters are viable options. Just depends on which one is better for architecture/perf.