Elevate requested privileges/scope for authenticated provider - hybridauth

For Hybridauth 3, what is the correct steps to elevate the scope of an authenticated user?
Say that a user has only used Hybridauth to sign in. This does not require very deep privileges. But then they want to enable posting of status for instance, or sending personal messages in Facebook. How do I, in the best way, handle the elevation of the requested privileges?
Do I just change the scope and authenticate again or is there some other flow?

Related

How do I login to okta without redirecting to the okta website for authentication?

I am using the below code :
https://github.com/oktadeveloper/okta-android-example/commit/5d01efe98b9a73937c8eeec92797117ad1f8a72b
for testing okta authentication, but it redirects me to the okta website for authentication and i would like to make it such that I don't get redirected for authentication, but remotely authenticate based on the credentials I enter in my app which upon verification and successful login send me over to my app dashboard.
Currently based on the above code, i am getting redirected to okta, i enter my credentials and then it kicks me back to the app which is not a very good flow. Anyone has any experience with this or any ideas how I can avoid redirection or any good examples online I can test out with ?
What you're describing is standard OAuth2 flow which is designed to ensure user never enter their credentials directly in the application. The intention here is to avoid your application being able to capture/cache the user credentials, which is really what the credential owner ( the user ) wants. OAuth2 is designed around redirecting the user to their identity provider, entering their credentials there, and authorizing the application to access resourcs on their behalf. It's a standard pattern these days.
However, for 1st party applications where there is trust there's an existing OAuth2 flow that will do what you want called the resource owner password flow. I'm not recommending you implement it, but it will allow you to capture the user credentials locally and recieve appropriate tokens in the response.
https://developer.okta.com/authentication-guide/implementing-authentication/password

OAuth 2.0 scopes as service identifiers for centralized authorization?

I am about to write a central service for authentication AND authorization in our company, let's call it C-AAA.
This central service is holding all user credentials. It is also equipped with a web-based user interface where administrators may assign access rights for different services (i.e. web applications) to specific users. These applications should now use a standardized method to ask C-AAA whether a user should be provided access or not.
The first thought which came into my mind was to use OAuth 2.0 as this allows us to easily provide the auth interface also to third party applications, mobile apps and so on.
The process I imagine is as follows:
A secured web application ("SecApp") is called by a user.
SecApp checks for an existing valid session (within the application).
If no session exists already, it calls C-AAA using a client secret and client id as OAuth suggests. Additionally, the applications sets a scope for the request, being her own name 'secapp'. If client id and secret are correct, an authentication code is returned.
Using the auth code, the user is redirected to the login on C-AAA.
The user provides his/her credentials to C-AAA.
C-AAA verifies them AND checks whether the requested scope corresponds with the roles associated with the user. ("secapp.user" and "secapp.admin" might be defined as valid permissions in this case.)
Only if both conditions are true, the user is authorized and an access token is generated.
The access token is returned to the SecApp application.
Information about the user's personal data and application permissions (user/admin) is fetched from the C-AAA.
The user information is stored in a session variable within the SecApp application and access is granted according to the returned roles.
The OAuth specification does not say too much about the use of scopes. Therefore, I am asking:
Is this a legitimate use of the OAuth 2.0 standard? If not, which method would you recommend in my case? (I'd really like not to reinvent the wheel and therefore stick with standards.)
Side note: C-AAA is implemented with Symfony2, using FOSUserBundle and FOSOAuthServerBundle.
Thanks in advance for your answers!
This looks like a good use case for OAuth.
Firstly, The C-AAA app is supposed to store not just the credentials but also the scopes.
Now looking at the points that you have mentioned, I would want to suggest one change in the flow.
In step 3 -> When user hits the SecureApp endpoint, and no active session is open, the user must log in and provide credentials.
Logging in should be a feature of C-AAA central identity provider. So, user is redirected from SecureApp to C-AAA portal where he logs in and the client gets an access token in return when the login attempt is successful. This login and access token generation is all happening between the client and the C-AAA module. {Notice how a popup opens up when we do a login via Facebook}
So, once logged in C-AAA returns a token to the client (THIS DOES NOT CONTAIN THE CLIENT SECRET). This is pretty much like a SSO. The access token with the client contains info about the user and the allowed Scope as encrypted data.
The client now hits any endpoint in your organisation with this access token (till the token is valid). The API's internally call C-AAA to authenticate the user and check if he has access to the requested operation.
The advantage of this approach is that you can with time create more endpoints within your organization and make sure they authenticate the access token provided with the C-AAA module.
I remember writing a more detailed answer here - How would an efficient OAuth2.0 server / provider work?
I think that it is not the role of the C-AAA to decide whether the user can access the application based on his 'role'.
The scope parameter is used to indicate a list of permissions, that are requested by the client
The applications must required (that is the role of the scope parameter) access to the 'role' of the user and, after validation of the C-AAA credentials, use this information to decide if it allows the creation of the session at the application level or deny access to the user.

Who can interact with Google Directory API?

The question look very easy to answer but the documentation is not really clear about that. I am using OAuth 2.0 to authorize requests but in the end, only administrators are able to use APIs, normal users will get an error. Am i missing something in my configuration or simply normal users are not allowed to use Directory API? As far as I can tell, it should not be possible but I see many reasons why instead it should be. For instance, in my applications I'd like to handle permissions based on user's OU. Unfortunately I couldn't find a way to do that because every call to the API must be authorized by an authenticated user. But what if that user is not an administrator?
For instance, if I try to execute this API example as a normal user I get the following error:
"Not Authorized to access this resource/api".
Whereas with an administrator account I can successfully retrieve the JSON result.
It makes sense that only the admin of the domain can use the Directory API (which is a subset of the Admin SDK) - only the domain admin has access to all the user data.
You can access the Directory API for the relevant domain using a service account - which will give you full access that was granted in the scopes by the domain admin when allowing your app. And afterwards you'll decide on your server-side which features you want to expose to "regular" users, and which you expose to the admins only.
But again, in order to do that, you need to find a way to implement a service account mechanism in your app.
I was commenting on the other answer since I think using delegation is overkill here and has security implications.
Just use regular server flow oauth2, no need for 2-step oauth.
make a page in your app for the domain admin to enter and set up the app permissions
in there, make an oauth flow to capture the refresh token of that admin user.
then follow the oauth docs to get an access token from that refresh token
there are google classes that do all that for you
To try it out quickly or to skip the oauth flow implementation and just hardcode a refresh token, go to the https://developers.google.com/oauthplayground/
there, add the needed scope for example https://www.googleapis.com/auth/admin.directory.user
follow until step 2, where it gives you a refresh token.
Of course step 1 & 2 need to be done from an admin account that has access to the permissions you need.
continue to step 3 to prove that this actually works, by making a call to the api you want.

How do you know if the current user is an admin with app engine cloud endpoints?

I know the endpoints module has a get_current_user function, but as far as I know, the user object has no property or method to find out if the user is an admin.
The first answer to this question was very helpful to me. It requires that you use the google+ sign in button, but that's a good temporary sollution. The reason I'd like to work something else out, is because I want to use this for admin console pages, in which case, the admin is already logged in to google, so having a google+ login button there looks weird.
An other way to implement this would be to make my own oauth system, where a script in the admin page makes a request to a a normal requesthandler, which requests if the user is an admin, and if so, returns a sort of admin token, which grants the user access to my endpoints methods. With every endpoints request, I'm already using such a token system in the user facing part of the application, because I can't use google accounts for the app. The token is only valid for a limited amount of time, and a limited number of requests.

Connect a salesforce user to another salesforce user in another org without any user intervention

We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.

Resources