How does data.wa.gov.au’s authentication system work?

Extending SLIP's authentication options to include OAuth2 is currently on the wishlist of SLIP enhancements. If you have a specific use case for OAuth2 please get in touch with the SLIP Services team - direct feedback on how you would use OAuth2 is valuable as the SLIP teams are prioritising enhancements.

SLIP Maps – maps.slip.wa.gov.au

When accessing a secure SLIP Map via a web browser using Internet Explorer, Chrome or Firefox, a token-based authentication (SAML/OAuth) is used to allow single sign-on.

This means that your username and password are requested only once, then future connections use the token or cookie to allow access. Clearing your browser cache or history will remove these cookies and you will be prompted to log in again. Using a private or incognito browser will not automatically log you in at future sessions and is best practice when using a public computer.

SLIP Data Services – services.slip.wa.gov.au

When connecting via a desktop, GIS client such as QGIS, GAIA or ArcGIS do not support the single sign-on token options SAML or OAuth and therefore use Basic Authentication.

This means that your username and password must be sent with every request. Generally these client applications will store the username and password within the application.

It is important to note that if you usually log into maps.slip.wa.gov.au by signing in with Google and want to use data services in a desktop GIS client, Google does not support Basic Authentication. Simply register a new SLIP account not linked to your Google account to use secure services in desktop GIS clients.

SLIP Data Snapshots - maps.slip.wa.gov.au/datadownloads/

The authentication system for geospatial data snapshots from SLIP is based on the OAuth 2.0 Authorisation Code Grant Type - this is similar to the authorisation flow you will have used if you sign into a site using your Google or Facebook accounts. It's a redirect-based flow that exchanges your credentials for an authorisation code, which in turn is exchanged for your authorisation token that allows you to access snapshots. For a more in-depth explanation please see DigitalOcean's article An Introduction to OAuth 2.0.

Customised Authorisation code grant type

SLIP's authentication for data snapshots is based on OAuth 2.0's Authorisation code grant type but has been customised slightly to permit use by automated systems and programmatic access.

Typically the user (a human) presents their credentials to the system and their web browsers follows a series of redirects to exchange those credentials for an intermediate authorisation code, followed by the final authorisation token.

That is the default flow for SLIP's Authorisation code grant type, but we also allow automated clients to pass their credentials in the header of a request in the same way as required by the older Basic access authentication method.

Automated systems can opt-in to this Basic authentication-style flow by setting the User-Agent header to SLIPAppUser.

With this customisation SLIP's authentication system provides a Basic access authentication-like interface that -

• Allows a client to provide a username and password (Base64 encoded in the HTTP Authorization header.)
• Returns a series of HTTP 302 Redirect responses that enables the client to exchange their username and password for an authentication token.
• Uses cookies during the authentication handshake process.

If you're familiar with Basic access authentication you'll notice this does not meet the standard definition of Basic Auth in that it both uses cookies and requires the client to follow redirects to complete the handshake.

For this reason you may find that software that supports accessing Basic Auth secured web resources may require additional configuration to work with SLIP's data snapshots. We'll go into more detail below on how to configure a few different pieces of software, but as a general rule any piece of software will need to:

• Be able to activate "Follow redirects" mode to honour HTTP 302 Redirect responses.
• Be able to pass the HTTP Authorization header with a Base64 encoded username:password combination for every request in the handshake, including other domains under *.slip.wa.gov.au.
• Be able to receive and send cookies between each request in the handshake.

Refer to our How To: Download Geospatial Data Snapshots article for several examples of traversing this authentication flow in Python, FME, and cURL.