oci-java-sdk
oci-java-sdk copied to clipboard
oracle
Support for OAuth authentication in the Rest API
Hi, We are looking for something like OAuth, via which we can login to OCI in JAVA sdk. Please let me know in case of any reference to APIs.
Hi,
Currently there is no OAuth authentication available. The only authentication methods available are:
- Using an API key: https://docs.us-phoenix-1.oraclecloud.com/Content/Identity/Concepts/usercredentials.htm#two
- Using instance principals/calling services from an instance as described here: https://docs.us-phoenix-1.oraclecloud.com/Content/Identity/Tasks/callingservicesfrominstances.htm
But when I login to web via link: login.us-phoenix-1.oraclecloud.com It shows oauth2 in url !!! something like https://login.us-phoenix-1.oraclecloud.com/v1/oauth2/authorize?action=login..................
Sorry for the confusion - federated identity is available via the console (https://docs.us-phoenix-1.oraclecloud.com/Content/Identity/Concepts/federation.htm) but if you are looking for authenticating against the APIs here: https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apiref.htm (apart from the S3 compatibility API, which uses AWS-like authentication via access keys and secret keys) then the only supported ways are using an API key or instance principals, as per the link in my previous comment
As an update, a backlog item has been logged with our Identity team to consider adding support for OAuth authentication support to the API. If it becomes a supported mechanism then we can look at adding support to the SDKs for this.
I'll leave this issue here in case different customers have the same question or wish to chime in on their need for this feature.
After more careful consideration the product team is not going to consider supporting OAuth for its SDK and CLI. The reason is that for running scripts and the Command Line using our signing spec is a better and more secure authentication than OAuth. OAuth is good, but it relies on bearer tokens, which cannot express intent to call a particular API. If in future we get a lot of request to support third party software calling into OCI then we will reconsider.
I'm not really sure I understand the push back here. The scope claim in OAuth is intended exactly for the purpose of restricting the APIs the token bearer is permitted to invoke.
Is there some other offering that allows API interactions via federated auth?
Our team prefers the current signing authentication method for the API. So we have no plans to support OAuth access for SDK/API. (See above for that reasoning). The scopes suggestion won't scale to our needs and we have no plans to support OAuth as a mechanism to access the SDK/CLI.
However, we do have some upcoming feature that will give Federated users access to the SDK and Command line. Is the core of your question getting access to the SDK/CLI as a federated user?
Any other followup needed here @cdockter @dipeen-oracle ? Looks like the Identity team considers this "won't fix"
I'm going to close this shortly if I don't hear any additional pushback.
I read the above response as "we don't want to and we don't care". If there was federated auth support for API access that might help but it is unclear what authN mechanism would be used.
Hey CDockter,
I'm happy to tell you that federated Auth support for IDCS shipped recently. So if you are using IDCS you can use the API with that federated user. We also intend to support more IDPs in the near future.
It'd be helpful if you could expand on your use case a bit. Is the case for an interactive user who wants to run scripts through the Java SDK? Is it a long running process or application that's running scripts with the Java SDK? Any more info would be helpful.
Thx -Martin
I think you missed the point here somewhat; I don't wanted federated "users", I want federated Auth.
The issue with the current offering is I still must provision API keys for every user I want to be able to access OCI recourse. Instead, I want to be able to auth against an external authority using its native mechanism and then present proof of that auth to OCI.
This is the basic workflow described in RFS-6749 Section-1.2. With OCI acting as the Resource Sever, this workflow would require a trust relationship between OCI and my federated Authority.
I understand if this doesn't fit in your current road map but the current IDCS is not very useful to me or I would guess most of the people interested in this issue.
Thanks for the clarification of the scenario. While we don’t have OAuth 2.0 support currently, we understand the importance of it for our ISV partners.
We want to build a vibrant ecosystem that allows ISVs to call into the OCI SDK from their apps (web, mobile etc). We do plan to support OAuth 2.0 eventually, but unfortunately we don’t have a short term plan to support it. Stay tuned for updates later in 2019 as we build out or ISV ecosystem..
Hey @cdockter, it's been a while since this conversation took place. I wanted to check in to see if you ever tried out token-based authentication in OCI CLI. You can do oci cli session authenticate which will direct you to the browser for login and, upon successful authentication, will get a token that will be used for future requests. Does it meet your requirement? Did you end up taking an alternate approach to solve your requirement?
Hi @cdockter and @dipeen-oracle , please let us know if you had a chance to look at the above message and try it. If not I will close this ticket soon. Thanks.
@cdockter and @dipeen-oracle, Closing this ticket for now. Please feel free to re-open if you have questions. Thanks.
I think the ask was simple enough, developers require an implementation of AuthenticationDetailsProvider they can use to configure the SDK using an OAuth token. As of now the SDK is shipped with:
meaning that if I have a bearer token obtained from: https://idcs-mydomain.idcs.identity.us-phoenix-1.oci.oraclecloud.com:443/oauth2/v1/token/ and I want to use if to create OCI SDK Clients (lets say java) there should be an: OAut2AuthenticationDetailsProvider (or the like) for me to use when creating a client
