I am using laravel passport for authorization from mobile app.
But I'm not sure where to place the client credentials i.e client_id/client_secret and redirect_uri.
Will it be placed at mobile app end and they will pass these to an API while authenticating to get tokens or these details be kept at server side in some env variables for security purpose?
And will the every user be having different client_id and secret or it will be same for all users throughout the application.
The client credentials grant type is for when you want your application to contact the server with out a user. For example a weather app will contact the server to get the latest weather data. It does not need to user to login to do this. You want to client credentials because you do not want everyone using your api. It is a way to protect your api and only allow your approved apps to access the api information.
Yes you will pass the client_id/client_secret from your mobile/desktop application to the /oauth/token url on your server so it will return an access token for you to use when getting all the information through the api.
The client_id and client secret do not need a user. It is for the client (Mobile/Desktop application). But it will be the same for every user since they all will be using the same mobile/Desktop application.
Related
I am trying to figure out how to perform single sign on with OAUTH2 on two different applications. Currently according to my understanding I can use the Authentication Provider in order to authenticate my clients. The procedure is the following:
The client is redirected to the Authentication Provider
Then the client is loggedin and has the code
The client provides the code to my application
The server uses the code in order to retrieve the access token.
Using the access token my server uses the remote API to retrieve information
Now I have a second application in a different backend (PHP) that I want to inform that the user is already loged in via the OAUTH. My naive solution is to provide the access token of the first application to the second application in order to perform the authentication. However, I understand that I am not allowed to share the access tokens between apps.
Every backend service should validate the access token via introspection. The only introspection guarantees that the token is valid, not expired or revoked.
So you have to pass the access token to the Backend service. To secure that you can use HTTPS API.
You are correct regarding not sharing the access token. The Authentication Provider should also allow creating an ID token. You would configure your second application with the authentication provider and get a client id. Both the client id and ID token are required to sign in the second app which will generate it's access token.
What grant type are you using?
Both apps need to redirect the user:
In the first app the user will authenticate and the app will get an access token scoped to that app.
In the second app the user will be automatically signed in without needing to reauthenticate. The app will then get a separate access token, generally with different privileges to that of the first app.
This is standard SSO behaviour and it is best to accept it. Usability is pretty good. Trying to share tokens is not advised unless you have advanced requirements.
I'm working with a company that is using the Google Apps free subscription. This company has a web site. They want to let users who have Google Apps accounts in their domain to authenticate into the web site via OAuth.
My question is, where do I find the ClientId and ClientSecret needed to do OAuth?
Thank you!
OAuth 2.0 for Client-side Web Applications will allow you to authenticate users using Oauth2. This will allow the users to grant your application access to their private data.
You will need to go to Google Developer console and create credentials on this page Credentials
Open the Credentials page in the API Console.
Click Create credentials > OAuth client ID.
Complete the form. Set the application type to Web application. Applications that use JavaScript to make authorized Google API requests must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.
I am developing an application using ASP.NET MVC 5.2.2, Web API 2.2 and Katana/OWIN 3.0. The application uses ASP.NET Identity 2.1 for local accounts and database.
I am using OAuth Authorization Server to generate access and refresh token. I have Android and IOS apps which uses my local oauth authorization server. Android and IOS apps uses SDK to login with Facebook, Google, etc. After that the apps will send the (Facebook/Google/etc) access token to the server. The server will validate access token with Facebook/Google/etc.
If it is valid then,
1) Should I generate new local access token(in Auth header) to apps
for all future request?
2) Should the app send me Facebook/Gmail/etc
access token(in Auth header) every time and the server validate the
access token with Facebook/Gmail/etc each time?
3) If local access
token expire, then the server is using refresh token to generate new
access token. Should the server update the access token as well as
refresh token during this time or updating access token is enough?
after you validate your social provider external access token, you need to exchange this external access token with a local access token issued by your authorization server (Local authority). All the details for this implementation can be found here: http://bitoftech.net/2014/08/11/asp-net-web-api-2-external-logins-social-logins-facebook-google-angularjs-app/
Let me know if this helps.
Here is the exact steps I have followed to change the external access token with access token issues by Local Authority. The front end is an AngularJS application. You can check the demo application here and see how I'm accessing the web api using Facebook access token http://ngauthenticationweb.azurewebsites.net/
1- AngularJS application sends HTTP GET request to anonymous end point (/ExternalLogin) defined in our back-end API by specifying client_id, redirect_uri, response_type.
2- Once the end point receives the GET request, it will check if the user is authenticated, and let we assume he is not authenticated, so it will notify the middleware responsible for the requested external provider to take the responsibility for this call, in our case it is Google.
3- The consent screen for Google will be shown, and the user will provide his Google credentials to authenticate.
4- Google will callback our back-end API and Google will set an external cookie containing the outcome of the authentication from Google (contains all the claims from the external provider for the user).
5- Google middleware will be listing for an event named “Authenticated” where we’ll have the chance to read all external claims set by Google. In our case we’ll be interested in reading the claim named “AccessToken” which represents a Google Access Token, where the issuer for this claim is not LOCAL AUTHORITY, so we can’t use this access token directly to authorize calls to our secure back-end API endpoints.
6- Then we’ll set the external provider external access token as custom claim named “ExternalAccessToken” and Google middleware will redirect back the end point (/ExternalLogin).
7- Now the user is authenticated using the external cookie so we need to check that the client_id and redirect_uri set in the initial request are valid and this client is configured to redirect for the specified URI.
8- Now the code checks if the external user_id along with the provider is already registered as local database account (with no password), in both cases the code will issue 302 redirect to the specified URI in the redirect_uri parameter, this URI will contain the following (“External Access Token”, “Has Local Account”, “Provider”, “External User Name”) as URL hash fragment not a query string.
9- Once the AngularJS application receives the response, it will decide based on it if the user has local database account or not, based on this it will issue a request to one of the end points (/RegisterExternal or /ObtainLocalAccessToken). Both end points accept the external access token which will be used for verification and then using it to obtain local access token issued by LOCAL AUTHORITY. This local access token could be used to access our back-end API secured end points.
Let's say, i want to develop a rest api implementation and use OAuth 2.0 with authorization_code grant. I will have apps, users, access_tokens etc. I just couldn't imagine only one scenario. When a user permits an app to use it, my auth server will redirects him to app site with auth code and then the app will post it with its client_id to fetch access_token. So, how can i link this access_code to the user? At last, the app will want to access to some resource about THE USER and will post the access_code which my auth server created to access it. Or just the app should store to link between access_code and the user id(but how can it determine the user, it is an another question).
The Authorization server have to provide a service to give the resource server user information but using access_token so the resource server can get user Id and other information to use it, example of it is using login with FB or google, it is providing user information to the 3rd party want to authenticate this user.
How do I secure my API when I want an app to be able to retrieve app-specific information without a user logged in and when I have an OAuth provider for another section of my API? Can I use the client app's OAuth credentials to hit the API without a user logged in?
I have create an OAuth provider and client using doorkeeper following railscasts 353. I can successfully authenticate a user to my provider app and make requests on behalf of the user to my provider API.
However, a portion of the API is user independent, meaning that the information returned from the API is not specific for a user and therefore a user should not have to be logged in. For example, assume an ecommerce site and items and prices are stored on the provider for multiple clients. I want a client app to be able to securely retrieve the items/prices associated the retrieving app without a user having to be logged in. So if you went to example.com the items would be displayed even if a user is logged in via OAuth.
I have only be able to retrieve this information via OAuth when a user has logged in through OAuth (creating an access_token). Is there a way to use OAuth without having a user present (I've been trying to read about 2-legged OAuth and if that is an appropriate solution)? Or do I need to use Api keys (or Http Basic Auth) for the application to retrieve the application specific data?
If OAuth is not the right solution because I do not have a user present, could/should I use HTTP Basic Auth over SSL and use the client site's OAuth secret key as the API key for the basic auth username?
If you need to authenticate your client apps in you API (without requiring a user specifically) use the Client Credentials flow