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)
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.
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.
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!
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 XLIII, The New SAS Developer Portal
Wednesday, August 14, 2024, at 10 a.m. ET | #SASBowl
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.
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.
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!
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 XLIII, The New SAS Developer Portal
Wednesday, August 14, 2024, at 10 a.m. ET | #SASBowl
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.
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 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
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.
Ready to level-up your skills? Choose your own adventure.