User-less Login to PLM 360

Let’s say you have a service that synchronizes data to PLM 360 in the background.  It’s a headless system, so there is no UI.  The problem is that PLM uses 3-legged OAuth 1.0, and “human” is one of the 3 legs.  There are lots of blockers to prevent a non-human from authenticating.  For example, there is no API to pass in the username and password.

The solution is to log in once as a human and save off the OAuth access token.  From an OAuth point of view, the access token is just as good as being logged in to the system.  This means that a background service can use that access token instead of needing to store username/password data.

Access tokens from Autodesk have an active lifetime of 2 days, but they can be renewed up to 14 days after they have been issued.  When an access token is renewed, a new token issued and the old one is obsolete.  This process can be continued indefinitely.  The only time a human would have to get involved is if the 14 day period expires before a token can get renewed.  In these cases, a human would again need to log in manually and store off the access token.

Let’s go over a specific example in PLM 360.  In step 5 of the authentication process, the human user has already logged in and your app gets the access token.  If you want to do an auto-login in the future, you should store off some of the data coming back from the OAuth provider. 

Here is a summary of the stuff we care about:

• oauth_token – The Access Token public key.
• oauth_token_secret – The Access Token secret key.
• oauth_session_handle – The session handle.  Needed to renew or force expire an access token.
• oauth_expires_in – How long, in seconds, the access token will continue allowing access.
• oauth_authorization_expires_in – How long, in seconds, the access token will allow a renewal.

You should store off the oauth_token, oauth_secret, oauth_session_handle, oauth_authorization_expires_in and oauth_expires_in.  You should also record the timestamp of when the token was issued.  The timestamp allows the application to calculate if a token is still active, needs renewing or is past the renewal point.

NOTE:  Make sure to store off the Access Token in a secure manner.  A compromised token is not as bad as a compromised username/password, but an attacker can still do a lot of damage with just the Access Token.

Now your app has a way to log in to PLM without user intervention.  It can just read in the saved OAuth data and continue to the next step in the authentication process.  The part that involved a human has already passed, so things can be automated from here on out.

When you want to renew your token, you will again call POST on https://accounts.autodesk.com/OAuth/AccessToken, but the input parameters are a bit different then when you first get the token. The oauth_token should be the current access token and the oauth_session_handle should be passed in too.  No verifier is needed.  The request should be signed by your Consumer Secret and Access Secret.

Example Request:

The response looks the same as when the token was first issued, but there are now new values for the Access Token, Access Secret and Session Handle. The old values are now invalid and cannot be used to access PLM 360.

Lastly, there may be cases where you want to invalidate the access token right now.  You don’t want to wait 2 days for it to expire.  You can do this by making a POST call to

https://accounts.autodesk.com/OAuth/InvalidateToken. As usual, this must be a signed request (use your Consumer Secret and Access Secret), with a bunch of oauth parameters passed in. It also requires that you pass in the session handle from the last /OAuth/AccessToken call.

Example Request:

If the call is successful, the Access Token, Access Secret and Session Handle are invalid and cannot be renewed.