We’ve made a number of enhancements to our API lately and wanted to take a minute to outline them for you.

First up, several API methods now support an expands parameter which will include extra data in the response. In many circumstances, this will improve your app’s performance by eliminating additional API calls that were previously required.

expands=memberships

expands=memberships is now honored for Get a user, Authenticate a user, Authenticate a key, Get an org, and Get a session. In all cases it will add membership data along with relevant users (Get an org) or orgs (the rest).

expands=custom

expands=custom will include custom attributes in responses to List users, List orgs, and List realms.

expands=token

expands=token, available on Get a session, will add a complete copy of the JWT token with the response. This is useful if for some reason you only have the session ID (instead of the entire token) or if the user’s data (name, memberships, etc) has changed and you want an updated token. It will leave the lifespan of the original token unchanged.

request

A couple of methods had support for ip and/or client attributes. This was very limited in scope and these old attributes are now deprecated. We’ve replaced them with a new request hash that contains both ip and client. More importantly, request is now available on nearly every API call that is capable of generating an event. The request hash will be attached to each generated event. Example:

POST /v1/users/text@example.com/authenticate
{ "password" : "secret",
  "request" : {
    "ip" : "192.2.0.1",
    "client" : "Firefox/38.0"
  }
}

LoginRocket logout

Logout has been added to the LoginRocket API.

CORS for LoginRocket

The LoginRocket API now supports CORS in addition to JSONP. CORS support is considered beta.

X-Request-ID

All API calls now return an X-Request-ID header which is unique to each request. It will look something like this:

X-Request-ID: rq_0vdbINw16QhITBp4iBhgX4

If you have a question about a specific API call, sending the request ID will make it much easier for us to help you debug the issue.

Passwords are a tricky thing. Ideally passwords should be easy for people to remember, yet hard for computers to guess.

The problem is that easy-to-remember passwords tend to be easy for computers to guess. Likewise, hard to guess passwords are typically hard to remember.

What’s the right level of complexity vs. convenience for your users?

Today we’re announcing several additional features that give you more control than ever in this decision.

Minimum length

Starting today, each realm can independently configure a minimum password length. The default for new realms is 8. Existing realms remain unchanged, but we encourage you to check and update this for realms used in production environments.

Minimum complexity

A growing number of sites now show some kind of password strength meter when users are selecting a new password. The quality of these algorithms varies. The algorithm “zxcvbn”, created by a Dropbox employee, has emerged as one of the best and is what we’ve implemented.

We’ve added a new minimum complexity configuration option available under Realm -> Settings -> Auth Providers -> Passwords. It works on a scale of 0 to 4, with 0 meaning disabled.

1 allows all but the worst of passwords, but does automatically enable the display of a password strength meter if you’re using LoginRocket, our hosted logins and signups feature.

2 through 4 require increasingly complex passwords. Complex can look like random letters (lower & upper), numbers, and symbols. However, it can also look like something longer yet easier to remember, such as “skip to my lou, my darling”.

When enabled, this will be enforced via the API, regardless of whether you’re using LoginRocket.

Required character sets

While we believe that the minimum complexity option above is generally the better (and more user-friendly) choice, we recognize that many corporate and enterprise environments have policies like: “passwords must contain at least 1 number and 1 symbol.”

To facilitate this, our Scale plan now allows you to require that passwords contain characters from one or more of the following sets: lowercase letters, uppercase letters, digits, and symbols.

Social-only

Lastly, password support can now be disable entirely. If you wish to allow logins only from Social Auth providers, skipping username/password logins entirely, we’ve got you covered. Simply deactivate the Passwords auth provider.

Questions?  We’d love to help.

Since launch, AuthRocket has supported sending emails in response to user events, such as welcome or password resets.

Today we’re pleased to announce that now you have much greater visual control over those emails.

In addition to sending emails as just text, now you can use Markdown or full HTML.

Markdown will automatically generate emails with both HTML and text. The HTML version will be built on a clean, responsive theme for a great look anywhere.

Full HTML allows a full, custom HTML look for the entire email, giving you complete flexibility. We will optionally distill down your custom HTML email into a text version too.

Markdown is the new default. Existing text-only email hooks remain unchanged, but you you may want to update them to Markdown for a more polished look.

We’ve added a few ways to help your user management along. You could already search in realtime for any user or org and sort the lists of users and orgs.

Now you can filter users and orgs by by user type, state, or creation date. You’ll find the new Filter button under both Users and Orgs.

Now you can easily see all users created in Q1 or user accounts created in the last 7 days.

Don’t forget, you can also export as CSV, exactly as you see it on screen. So if you filter for Active users, created in the last 90 days, sorted by Last Name, your CSV will be generated the same way.

That’s it for now. Questions? Comments? We’d love to hear from you.

Today we’ve added another Social Authentication provider to our growing list: LinkedIn.  We added LinkedIn due to requests from our users.  If you would like to see us add support for a particular social auth provider, please let us know.

As with the other providers, we’ve completely handled the integration so that you don’t have to.  If you already have logins working with AuthRocket, there is no additional coding required.

The details are found in our LinkedIn Documentation.

Social auth is currently in beta but is fully functional for Facebook, Google, and LinkedIn.  Additional providers will be added before full release.

Questions?  Let us know how we can help you get social auth working for you.