How can I generate client id and client secret for user based authorization.
I am reading this link to authorize an user. But I have no idea on generating these keys and want to authorize many users based on these keys in ruby. Any starting guidance is appreciated. Thanks
OAuth is generally used to authenticate users for your site by having them log into an external service (i.e. Facebook or Google). The OAuth keys are generally generated by the outside service. Rails has some solid user authentication gems such as Devise that include protocols for common OAuth providers.
You would get it from the Oauth provider you are using. For Google for instance you would create a new project on console.cloud.google.com or use and existing project from there. Then you would go to api's and services. Then you would set up credentials and your Oauth consent screen.
Related
By reading Cognito Identity Provider document, I understand that it looks like it provides out-of-box integration with Facebook / Google / Twitter as Identity Providers.
My application is a developer focused application so I would like enable users sign-up/sign-in with their Github account besides the above Identity Provider's accounts. Is that possible?
If possible, how much extra work (comparing the out-of-box Facebook/Google social sign-up feature) I need to do?
Since first writing this answer, I implemented and published a project that provides a wrapper for Cognito to talk to GitHub. It comes with a SAM/cloudformation deploy script, so you can create a CloudFormation stack that provides the wrapper very easily.
So, OpenID Connect is built on top of OAuth2.0. It's an extension - in OpenID Connect, the OAuth endpoints are there (with one or two extensions or changes), plus some new endpoints.
My understanding from reading the Cognito documentation and the relevant bits of the OpenID Connect and OAuth2.0 specs is that Cognito only uses four of the OpenID endpoints - Authorization, token, userinfo and jwks. You can specify each endpoint separately when configuring an OpenID Connect provider in Cognito. This means it is possible to provide OpenID Connect for github by implementing these endpoints.
Here's a rough plan for implementation:
Authorization: In the spec, this looks to be the same as the OAuth2.0 endpoint (plus some additional parameters that I don't think are relevant to using github as an identity provider). I think you could:
Use the github Auth URL: https://github.com/login/oauth/authorize
Set your GitHub OAuth app to redirect to https://<your_cognito_domain>/oauth2/idpresponse
For the other endpoints, you'll have to roll them yourselves:
Token: This is used to get the access and ID tokens - using a code returned by the authorization callback. It looks the same as the OAuth2.0 endpoint, but also returns an idToken. It looks possible to make an implementation that passes through the code to github's token endpoint (https://github.com/login/oauth/access_token) to get the accessToken, and then generates an idToken, signed with your own private key.
UserInfo: This doesn't exist at all in OAuth2.0, but I think that much of the contents could be filled in with requests to the /user github endpoints (since at this point the request contains the authenticated access_token). Incidentally, this is the reason that there's no open source shim to wrap OAuth2.0 with OpenID connect - OpenID connect's primary contribution is a standardised way of communicating user data - and since OAuth doesn't have a standardised way to do this, we have to write a custom one specific to GitHub (or any other OAuth-only provider we wanted to use for federation).
JWKS: This is the JSON Web Key Set document containing the public key(s) that can be used to verify the tokens generated by the token endpoint. It could be a flat file.
I have implemented the above, and the approach works. I open-sourced the project here.
Unfortunately it's not possible. Cognito Federated Identities can support any OIDC Identity Provider but OAuth2.0 spec does not give that flexibility, so there's no easy way to achieve this unless we add special support for Github.
Here is I have a small problem of architecture, first of all, I have two applications:
An api writes symfony 3.3
A front writes too it symfony 3.3
Then, I would like have two manner to sign in:
the first one by using of third application such as Facebook, Google or Twitter. For this part I thought of using hwiOauthBundle
Or simply by login / password. Here I thought of using FOSUerbundle
Finally I would like to have secure api, that a not connected user cannot reach the resources of the api.
What do I have to install or to develop to have all the expressed criteria higher?
In advance, thank you of your answer.
You have to setup some kind of login proxy endpoint that has the oauth client_id and secret.
Then with the username and password given by the user you have to query the backend oauth token endpoint to get an accesss token.
After that you just need to sign your request to the backend with that token.
In my case I'm using FosUserBundle for user management, FosOauthServerBundle for the Open Auth management. Both are installed in the backend.
Once installed you have to register a aAuth client. This tutorial was really helpful for me OAuth2 Explained
I am prototyping HipChat client and I'm stuck at building good authentication experience. I would like to implement similar authentication dialog as HipChat clients built by Atlassian provide. There is no need to generate auth tokens/etc, you just type email/password and client is able to obtain oauth token.
How do they do? Clients use com.atlassian.hipchat.win-clients as client_name in request to https://www.hipchat.com/users/authorize.
Question that I have: how do I register my own client? If I use any random name I get "Named OAuthClient not found ".
How to register client name that will work with any HipChat server, including hipchat.com?
Updated:
I made an example. Please take a look.
https://github.com/chenghuang-mdsol/StandupCat
#VitaliyGanzha
There's a way I used: Build an auth provider based on the integration token.
Make an integration, take down the auth_token.
Use this auth_token on the api here: https://www.hipchat.com/docs/apiv2/method/generate_token
use grant_type 'password', and fill username and password in your post request.
It will return the user info.
Based on the user info it returned, you do your membership provider.
Note that this auth_token has very limited permission. If you want to do more than authentication, you need another personal auth_token which can be generated in your account center.
Tested in C# WCF
Here I've got an answer that it is not possible right now:
This is currently not possible. The flow you described with the
com.atlassian.hipchat.win-clients oauth id is used internally inside
our new desktop and mobile clients. The only other way to obtain an
access token via a 3-legged oauth flow is to create an add-on that you
have to require a HipChat customer to install. Our OAuth tokens are
scoped by group. We don't have allow global tokens. Sorry about that.
https://answers.atlassian.com/questions/32989448/writing-hipchat-client-hipchat-authentication
Does Directory API support authentication with OAUth2 Service Accounts flow?
I tested the serviceAccount.php google-php-api-client example using the scopes https://www.googleapis.com/auth/admin.directory.group and https://www.googleapis.com/auth/admin.directory.user and it didn't work.
You need to authorize the service account client ID to access the given API scopes in the Google Apps Control Panel. See the step as described in the Drive API docs, just sub in your Admin SDK scopes.
Note that IMHO, there's very little advantage to using a Service Account with Directory/Reporting APIs as you still need to impersonate a user who has super admin (or proper delegated admin) roles in order to perform and API calls. To me it makes just as much sense to just get a 3-legged OAuth 2.0 refresh token which supports offline from the admin. 3-legged can be done entirely programmatically where-as Service Accounts require the manual step above.
Short answer: Yes. #emilylam question comments hint the error.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.