I am a greenhorn of WSO2 ESB and confusing with configuration of gmail connector.
Based on the document (https://docs.wso2.com/display/ESBCONNECTORS/Configuring+Gmail+Operations), I have to fill gmail init element as below,
In my thought, the accessToken and refreshToken are only generated dynamically after user consent in OAuth2 and will expire in certain time. So why need to write these into init part?
In the integration use cases, One of the main issues is accesstokens getting expired and need human interaction to continue the service.
From connector side, This method added to renew the tokens using refresh token.
Yes you are correct the accesstoken and the refreshtoken are generated dynamically and the accesstoken only expired. There is an option to refresh the accessToken using refreshtoken in most of the API's. If the connector doesn't have any mechanism to create the accessToken using refresh-token then user need to interact to do this part and to replace the accessToken every time after expiration. But Connectors doing this part itself dynamically. First time you need to give the accessToken and refresh-token to this configuration after that connector itself handle the refresh-token flow and create the accessToken using refresh-token. So this will omit the user interaction in middle.
Related
it is possible to login a user from firebase jwt to django if so, what is the tools needed to login a user? Thanks
It sounds like you want to use the Firebase Authentication status of the user to authorize them in your Django code. This is indeed possible, and described in the Firebase documentation on verifying ID tokens. The process is:
Retrieve the user's ID token (a JWT indeed) on the client, as shown here.
On the server, either use the Admin SDK or use a 3rd party library to verify the ID token.
Use the information from the token to determine whether the user is authorized to perform the action they're requesting.
I have a Django Rest API with JWT authentication which is the backend for a Angular frontend. There are many clients who use the service with our frontend. Now some enterprise clients wanted to integrate the APIs from their system's backend. I don't want to remove JWT from current APIs. I am planning to create new APIs in the same backend with OAuth token for those users.
I wonder what is the best way to implement OAuth for this scenario.
I am thinking Client Credentials grant type is the best way.
Question1: Am I right that client credentials is the right approach ?
For those enterprise users, it is sufficient they get just access token through the UI interface so that they can access all our APIs.
But here the problem is one additional step of getting the Client ID and Client Secret first and using that to get Access Token.
Question 2: What is the use of client ID and client secret ?
Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?
Question 4: If I am giving them Access Token without client id and secret, is that fine to have infinite expiry time? and
TLDR; How to implement OAuth when the resource server and auth servers are same ?
There are 4 grant types in oAuth2 which is meant for different scenarios.
client credential : the consumer (app) make calls to back-end using the bearer token created using apikey(or clientId) and secret only. Mostly used for anonymous calls where generic information is retrieved.
Resource owner password credential (ROPC) : the consumer (app) make calls using the bearer token created using apikey, secret, username and password. Mostly used when you(your authorization server) already know the users(user database is handled in your own system).
Authorization code : the consumer (app) make calls using the bearer token created using an authorization code. The authorization code is provided by a 3rd party (which actually has/manages the logged in user data) and the created authorization code linked to the logged in user. Google and Facebook log in for various sites is a typical example. Facebook/Google gives an authorization code for those websites and they exchange that code for a token.
Implicit grant : Mix of password credential and authorization code. Instead of authorization code, you get a bearer token from the 3rd party authorization server.
Question1: Am I right that client credentials is the right approach ?
I think you can use CC if there is no user level logics in your backend. If userlevel involved, may be ROPC is a better choice
Question 2: What is the use of client ID and client secret ?
Client ID and Client Secret is very similar to username and password in an application level, which is used to obtain bearer token.
Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?
If you are implementing oAuth2, your consumer should create the access token. But looking at your use case, may be even a simple hash of userId+timestamp is sufficient. ;)
Question1: Am I right that client credentials is the right approach ?
Yes. Providing the new APIs do not need to be called in the context of an end user.
Question 2: What is the use of client ID and client secret ?
The client ID allows the auth server to identify the application
requesting the token (it's often carried through to the access token
too, allowing the API to identify the calling application).
The client Secret means the auth server can trust that the client is
genuinely who he says he is as only he should have the private client
secret for his public client ID.
It's effectively a username and password in this scenario.
Question3: Should my backend hide the process of generating Client ID
and Client secret and just give Access token (or) give them Client ID
and Client Secret and ask then to generate access token ?
Your Auth server should issue the client credentials to the application once and the application should provide those credentials every time they wish to obtain a token via the client credentials grant type.
authorization code grant, or implicit grant might be more suitable for this scenario. The first one allows you to add an authentication step before the tokens are returned to the users (might be useful if you want to integrate your JWT authentication to this as well) and the second one is mainly used for single-page applications, and does not include an intermediate authentication step. This one would be useful if you want to improve efficiency.
client_id and client_secret are given to you when you register a client application in your identity provider(authorization server). This client application does not mean an application or an API belonging to your clients, but your own application to which you plan to incorporate OAuth(and OIDC). These two parameters are useful when making the requests to authorization in order to obtain tokens. The server uses those values to determine whether the request is made by a valid application. Only you have access to those values as you will be the one who's registering the application with the server.
I think this question is answered in the previous section.
I think it would be better if you go through this before doing any implementation. It provides most of the basic knowledge you should have before implementing an OAuth system. I hope this answer was useful to you.
I am using aws Cognito for user authentication in my android application, I want that once the user log ins into the app, he should be able to auto login into the app. unless he logs out of the app. Can anyone give me any pointers on how i can implement it?
At this moment cognito android library manages it for you. Library would refresh idToken and accessToken, you just need to retrieve them each time from the library and try not to store/cache for a long anywhere (both are valid for 1 hour). getAuthenticationDetails() method (used to get your credentials) wouldn't be triggered, until refresh token is valid.
The library is using refresh token to refresh idToken and accessToken. Refresh token is valid (by default) for 30 days from last login. You could extend the value to 3650 days (max), but currently android library doesn't support this feature.
I'm building a manual login flow for my App which is integrating some facebook functionality.
I need to check when the current access_token of the user will expire.
The API documentary says I should do this call:
GET graph.facebook.com/debug_token?
input_token={token-to-inspect} &access_token={app-token-or-admin-token}
So I did this in C#:
Uri inspectAccessTokenUri = new Uri("http://graph.facebook.com/debug_token?input_token="+access_token+"&"); //IDK which value should have the last parameter
HttpWebRequest checkToken = (HttpWebRequest)WebRequest.Create(inspectAccessTokenUri);
var response = await checkToken.GetResponseAsync();
Stream stream = response.GetResponseStream();
StreamReader reader = new StreamReader(stream);
string data = reader.ReadToEnd();
Debug.WriteLine(data);
The last parameter should be the app-token:
BUT: Of course I looked up how to get the app-token and facebook says:
Note that because this request uses your app secret, it must never be
made in client-side code or in an app binary that could be decompiled.
It is important that your app secret is never shared with anyone.
Therefore, this API call should only be made using server-side code.
(Facebook Graph API Documentation 1.1.16)
So my question: Can I check the token without the app-token or hardcoding the app-secret?
App secret is usually used by the server-side app, we don't use it in our UWP app, it could be decompiled.
Read the official doc about FB Graph Debug-Token, this can only be used when you debug your app, for example if you want to check the metadata about a given access token, after you publish your app, your code will not relay on it.
In an UWP app, we use WebAuthenticationBroker class to connect to OAuth providers such as Facebook, Flickr, Google, and Twitter. Maintenance is need during using OAuth connections. For example, expires information is included in the access token, when we use OAuth protocol for authentication and authorization, we need to refresh the access token after it expired.
Due to these conditions, you may reconsider what you can do in an UWP app and which API you should choose.
If the app-token is expired you will get a facebook response error. And you can catch this exception to deal with the situation you want. In this way you don't need to make a request with your app secret.
You can also use fb-uwp sdk that contains AccessTokenData for authenticated users
I am doing some work in Django, using the Django Rest Framework.
Users login via Oauth2 to facilitate integration with mobile applications.
I am using the Oauth2 authentication library that is packaged together with the Django Rest Framework.
To logout a user, I am expiring their access tokens, is this the correct way of doing things?
It's not correct. Normally, the access token expires when it reaches its expiration time.
Or in some these cases:
1. User revoke this access token.
2. Users change their password.
3. When refresh token is revoked, its issued access tokens will be deleted.
And here is a reference about log out.
I think what you mean is that you are creating a oauth2 provider?
If I am correct I would recommend switching to using token authentication. To create a oauth2 provider there are many restrictions and rules to follow and I assume when you create a oauth2 provider that it will be a public system that can be used by many people (that can and will misuse your service if it's has leaks)