BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Ullsokk
Pyrite | Level 9

I am building an internal application that will upload a dataset to CAS and trigger the selected Model Studio Pipeline. I have been using a refresh token in my stored process, but I now see that the toked has expired after 30 days, and it seems like there is no way to extend the refresh token validity. Extending the access token validity to any arbitrary length seems to be possible however. This seems a bit backwards to me, but okay. The stored process is run in a 9.4 environment.

 

What is considered the best practice for keeping such an application in use over time? Should I create a program that retrieves a new refresh token every month? Should I just use the refresh token once, and store the access token directly in the program? Or just skip the refresh token and utilize a user and password for authentication? Since this is running on 9.4, I guess I cant use the auth= SAS_USER (cant find the exact wording, but remember seeing this somewhere)

1 ACCEPTED SOLUTION

Accepted Solutions
joeFurbee
Community Manager

Hi @Ullsokk,

Lots to cover here. I'll try and be succinct. Best practices here fall under the classic answer of, 'it depends.' I'll try and lay out the facts and possible solutions and we can go from there.

 

First, depending on how things are set up you can use proc http and oauth_bearer=SAS_SERVICES (you reference as SAS_USER in your original post). I recommend looking at this SASGF paper (especially the documentation in the References section). 

 

Now let's consider the access token scenarios. We'll look at three different grant_types:  password, authorization code, and client credentials. Details of what's explained below can be found in this SASGF paper on OAuth by @MikeRoda. You have also seen my SAS Users blog post on Authentication to SAS Viya. Finally, my colleague @tarastclair has a great series on deciding which grant type to use and gives examples on how to register the clients.

Passowrd

It's not recommended to use password authentication, even in an internal environment. Refer to the docs if this is the way you want to go.

 

Authorization code

Facts

  • the access token has a default ttl of 10 hours
  • the ttl is configurable and has no limit
  • the refresh token ttl default is 30 days
  • default can be shortened, but not extended
  • need new authorization code after 30 days

This approach is recommended if you have a specific user needing access. Remember, when you can use the same refresh token to get a new access token for 30 days, but not longer. At that point you'd need to get a new authorization code for a new access token.

 

Solution 1 could be get the access token (manual) and keep renewing it using the refresh token (scripted) until it's revoked. You have many options for this: a daily process, an hourly process, every X call, etc. 

Solution 2 could be to extend the life of the access token from 10 hours from the get-go; however, the longer the access token lives, the less secure. 

 

The ttl of 10 hours for the access token and 30 days for the refresh token are there for security. If you made calls to a Google Analytics API, you'd want to re-up on authentication/authorization  more than once a year!

 

Client credentials

You can use the client credentials grant type when you don't care about a particular user's access.  You configure scoped authorities in SAS and use them when registering the client. This gives you freedom to choose the access token's ttl (configured at client registration) and there is no concept of a refresh token. You'd programmatically figure out when the token will expire and get a new one prior to it's expiration.

 

Whew. This response is pretty involved. I hope you're able to follow my progression enough to understand the different grant types, when to use them, and how to register your client appropriately. I highly recommend referencing the papers and posts I listed earlier.

 

Thanks,

Joe


Join us for SAS Community Trivia
SAS Bowl XXXVI, Data Simulation
Wednesday, December 13, 2023, at 10 a.m. ET | #SASBowl

View solution in original post

3 REPLIES 3
joeFurbee
Community Manager

Hi @Ullsokk,

Lots to cover here. I'll try and be succinct. Best practices here fall under the classic answer of, 'it depends.' I'll try and lay out the facts and possible solutions and we can go from there.

 

First, depending on how things are set up you can use proc http and oauth_bearer=SAS_SERVICES (you reference as SAS_USER in your original post). I recommend looking at this SASGF paper (especially the documentation in the References section). 

 

Now let's consider the access token scenarios. We'll look at three different grant_types:  password, authorization code, and client credentials. Details of what's explained below can be found in this SASGF paper on OAuth by @MikeRoda. You have also seen my SAS Users blog post on Authentication to SAS Viya. Finally, my colleague @tarastclair has a great series on deciding which grant type to use and gives examples on how to register the clients.

Passowrd

It's not recommended to use password authentication, even in an internal environment. Refer to the docs if this is the way you want to go.

 

Authorization code

Facts

  • the access token has a default ttl of 10 hours
  • the ttl is configurable and has no limit
  • the refresh token ttl default is 30 days
  • default can be shortened, but not extended
  • need new authorization code after 30 days

This approach is recommended if you have a specific user needing access. Remember, when you can use the same refresh token to get a new access token for 30 days, but not longer. At that point you'd need to get a new authorization code for a new access token.

 

Solution 1 could be get the access token (manual) and keep renewing it using the refresh token (scripted) until it's revoked. You have many options for this: a daily process, an hourly process, every X call, etc. 

Solution 2 could be to extend the life of the access token from 10 hours from the get-go; however, the longer the access token lives, the less secure. 

 

The ttl of 10 hours for the access token and 30 days for the refresh token are there for security. If you made calls to a Google Analytics API, you'd want to re-up on authentication/authorization  more than once a year!

 

Client credentials

You can use the client credentials grant type when you don't care about a particular user's access.  You configure scoped authorities in SAS and use them when registering the client. This gives you freedom to choose the access token's ttl (configured at client registration) and there is no concept of a refresh token. You'd programmatically figure out when the token will expire and get a new one prior to it's expiration.

 

Whew. This response is pretty involved. I hope you're able to follow my progression enough to understand the different grant types, when to use them, and how to register your client appropriately. I highly recommend referencing the papers and posts I listed earlier.

 

Thanks,

Joe


Join us for SAS Community Trivia
SAS Bowl XXXVI, Data Simulation
Wednesday, December 13, 2023, at 10 a.m. ET | #SASBowl

Ullsokk
Pyrite | Level 9

Thank you for the in depth reply! 

 

This was very helpful. So far, I have been aiming for the authorization code path. One sollution for me would be to store the active refresh token in a file or datatable, and have a batch job each 30 days update the refresh token, as long as that process can be fully automated. But it seems like this is set up to be a manual cut and paste, but I suppose I should be able to scrape the authorization code, if I can retrieve the redirect url. 

 

If not, I suppose I have to try the Client Credentials route in stead. The API request is sent as a proc http form a stored process on our sas 9.4.environment, triggered from an internal application. As such, the security concerns are not as dire as they would be from an application on the open web. The application uses single sign on and active directory to mangage access, so unless the client credentials are leaked this should have several layers of security in place.

Ullsokk
Pyrite | Level 9

So we finally found a much easier solution to authentication than the road we were on. Using auth=SAS_SERVICES is not possible from SAS 9.4 stored process, so we got locked into the access token path. But using SAS_SERVICES is possible from a VIYA Job (the viya equivalent of a stored process). So the solution was simply to execute the code as a VIYA job instead. So obvious in hindsight, but for some reason I did not think of it before. 

SAS INNOVATE 2024

Innovate_SAS_Blue.png

Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Get the $99 certification deal.jpg

 

 

Back in the Classroom!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 3 replies
  • 2877 views
  • 6 likes
  • 2 in conversation