Authentication

The Wurl API leverages the OAuth2 protocol to allow applications to request access to a user's details without requiring the user to provide the application their password.

In addition to serving as an OAuth provider for your application, Wurl can also act as a proxy for other OAuth providers such as Google. This allows your application's users to login using their Google credentials. The Wurl API can support other OAuth providers such as Facebook, or even your own custom OAuth provider.

OAuth providers for Applications usually have a "chicken and egg" problem. You can't make authenticated calls to the API until you have written your application, but in order to write and test an app, you need a token.

See the Authentication Guide for information on obtaining tokens, granting rights and using the proxy.

Security Considerations

Prefer Access Tokens

When making API calls to Wurl, it's preferable that you provide an access token unique to each user instead of your application's application-id and secret.

The primary reason to utilize an access token is to protect your application and users from abuse. If your application is making too many requests either from abuse or mis-configuration, we can disable individual access tokens. However, if you use the same token or your application's application-id/secret, then disabling those tokens will affect your entire application's user base.

In addition, we will be implementing rate limiting on a per token basis. This allows us to provide an adequate level of service to all users. If an application uses only it's application-id/secret or hard-codes a token for all users, then many users will get intermittent request failures due to request throttling.

When asking for support

At Wurl we will never ask you for your token for support tickets. As long as we know the ID of the Application (and possibly the the email of the user who can't make a request, if your problem is user-specific), we can replicate any problem without sharing tokens.

When sharing links

Sometimes your team will need to share API URLs. If your links have an access_token parameter remove it, and in general make sure that links with tokens are not forwarded outside your organization. Tokens are meant to be secret and treated with the same considerations a password would be.

The same holds true for your Application's secret. Having the application-id and secret allows service calls and token creation with any access level known to your Wurl application.

Authentication

The Wurl API leverages the OAuth2 protocol to allow applications to request access to a user's details without requiring the user to provide the application their password.

In addition to serving as an OAuth provider for your application, Wurl can also act as a proxy for other OAuth providers such as Google. This allows your application's users to login using their Google credentials. The Wurl API can support other OAuth providers such as Facebook, or even your own custom OAuth provider.

OAuth providers for Applications usually have a "chicken and egg" problem. You can't make authenticated calls to the API until you have written your application, but in order to write and test an app, you need a token.

See the Authentication Guide for information on obtaining tokens, granting rights and using the proxy.

Security Considerations

Prefer Access Tokens

When making API calls to Wurl, it's preferable that you provide an access token unique to each user instead of your application's application-id and secret.

The primary reason to utilize an access token is to protect your application and users from abuse. If your application is making too many requests either from abuse or mis-configuration, we can disable individual access tokens. However, if you use the same token or your application's application-id/secret, then disabling those tokens will affect your entire application's user base.

In addition, we will be implementing rate limiting on a per token basis. This allows us to provide an adequate level of service to all users. If an application uses only it's application-id/secret or hard-codes a token for all users, then many users will get intermittent request failures due to request throttling.

When asking for support

At Wurl we will never ask you for your token for support tickets. As long as we know the ID of the Application (and possibly the the email of the user who can't make a request, if your problem is user-specific), we can replicate any problem without sharing tokens.

When sharing links

Sometimes your team will need to share API URLs. If your links have an access_token parameter remove it, and in general make sure that links with tokens are not forwarded outside your organization. Tokens are meant to be secret and treated with the same considerations a password would be.

The same holds true for your Application's secret. Having the application-id and secret allows service calls and token creation with any access level known to your Wurl application.