I am implementing a Social Network authentication workflow, with a specific app, where on server side (left) there is a REST service to which the client (center) makes API calls. The goal is to validate on server side the authenticity of the user using Twitter API, i.e. the user first authenticates against Twitter, and then makes calls to a secure server, which must validate the API calls by means of a user_token included in the calls' parameters by the user. Have a look at next image:
STEPS:
The user connects to Twitter, and authenticates, asking for user_token
Twitter API returns an app_user-id (in the scope of the app) and a user_token.
The client sends an API call to server side with the app_user-id and the user_token.
The server connects to Twitter asking for an bearer_token by sending the app app_key and app_secret.
Twitter API responds with a bearer_token.
The server tests with Twitter API the user_token received from the user in step 3 and the bearer_token just received in step 5.
Twitter API responds validating the user.
The server considers the call comes from a legitimate user and delivers the output of the call to the her/him.
Regarding this, I have a couple of questions:
Is this a right way/protocol to validate user calls to the REST service on server side by using Twitter API authentication?
Thank you.
Related
Suppose that I have a mobile app with a frontend and a backend server.
My understanding is that -- when a user logs in the app with "Login with google", the frontend sends a request to the google auth server, and gets back an ID token. The documentation says that the frontend can then send the token to the backend server to establish a session. I imagine that means the token can be used in session-based authentication?
If I were to use token-based authentication (as opposed to session-based), do I just attach the ID token in every server request, and have the backend verifies it each time when processing a request? this page suggests the ID token should not be sent to the backend API. Which leaves me wonder what the correct procedure is for token-based authentication when using log in with Google.
So my question is: Does my server need to create an access token from the ID token from Google, and send it to the frontend, so the frontend can attach that access token in the API requests for authentication?
Thanks
Login with Google is an identity provider (IDP) operation. A full OAuth solution, including an authorization server (AS) looks like this:
Mobile app uses system browser to redirect to AS
AS returns a redirect response to the system browser, which routes to the IDP
User signs in at the IDP
IDP returns an authorization code to AS
AS swaps it for IDP tokens and carries out validations
AS issues a set of tokens to the app. This includes an access token (AT) with whatever scopes and claims are needed for business authorization to work.
Mobile app sends AT in API requests
API authorizes using scopes and claims from the access token
So ideally plug in an authorization server, to get this out-of-the-box behaviour. Another option is to implement your own token service, and issue your own tokens. That is less recommended though, since it requires more detailed understanding of the underlying security.
We have a system with three layer includes API Server (Backend), Client Web Site, and End User. Now, the Authentication occurs on API Server, which be done in two case. In one case, Client Web Site call API directly using a token (Client Token) which get from a service based on user/pass and in another case, besides End User login into API Server using Client Web Site, but authentication occurred on API Server other than Client Web Site. Client Site get another token which named as Auth Token (for end user calling), then call API that End User requested by sending two mentioned tokens. By using Client and Auth Tokens, API Server checks whether client and end User are logged in respectively or not. Entities and their relations are illustrated in here
I want to use API Manager as a gateway between API Server and Client Site and manage authentication process with it.
How can I implement this scenario using WSO2 API Manger?
thanks for your response!
Extending the previous answer..
If the backend is behind the API manager (adviced), the API maanger can pass the client/user/application information to the backend as JWT token. So indeed, that's a good use case to use the API Manager
Edit: extending answer based on comments
in one scenario when a user login to client website, it pass the user
& pass to API server. therefore, API server checks the validity of U&P
Indeed, using the default OAuth (code or password profile) will work.
and creates a Auth token as well creates a session for user.
Almost good. A token is returned, there's no user session in API Manager. All authorization is based on the token provided.
of session, that whether Client web site and end user
are logged in or not. the checking process performed by two tokens
Nope. The APIM doesn't check for any session. It checks only the OAuth (Bearer) token.
and in another scenario client web site call API directly without any
request from end user.in this scenario auth token is not exist
The web site (lets call it Application) can authenticate using its own credentials (so called client_credentials profile). It may receive its own OAuth application token.
The same feature is supported in APIM. You can simply get rid of authentication login from your backend (or replace with a simple one) and use APIM Authentication.
APIM uses OAuth2. To cater your requirement, you can use different grant types. For client website, you can use client credentials grant type, and for end users, you can use other grant types such as password or authorization code.
For more details read:
https://docs.wso2.com/display/AM210/Quick+Start+Guide
https://docs.wso2.com/display/AM210/Token+API
I'm developing a private API for a mobile app. I plan on securing and authenticating logged in users using JSON Web Tokens.
When a user authenticates and logs in to the service, the server will return a signed JWT in the response. The device stores this securely and sends it back as an HTTP Authorization header in every subsequent request.
So far so good. However, where I'm a bit puzzled is this: the token is generated for a new user when their account is created (ie they registered). This API endpoint (POST to create) is open and there is no token verification (naturally since it's a new user).
How can I ensure that POST requests to create new users are only authorized from the mobile app? In other words, if a malicious user sends POSTs to create spam users, how do I recognize this?
The API is over https. Though, even if I were to require the app to use an API key as a query param, that would expose it on the wire. I suppose I could pass in a Basic Header with a hashed API key/Secret.
What is a way to do this securely?
Edit: How to protect the 'public' part of a REST service from spam?
I am in the midst of planning a saas app and have been stuck trying to figure out how I want to handle my session management. Here's the scenario:
Server 1: REST API, Rails 4 w/ rails-api gem
Server 2: Front-end, Rails 4, BackboneJS/MarionetteJS
These servers, eventually, will be part of a cluster of similar servers.
The applications are separate because there will also be a mobile app using the REST API and we plan on having 3rd party applications tie into our database via the API.
I've boiled it down to 2 scenarios:
1) Use access_tokens only for authentication on the front-end:
User logs in and sends over email and password over https
They are authenticated via the api and it returns an access_token
All future requests made on the front-end use this access token
2) User database sessions on the front-end and then access_tokens for api calls
User logs in and is authenticated via devise on the frontend server (storing session info in the DB)
An access_token is generated for them and added to the Backbone app initialization for future api requests
I favor #2 simply because every time the user changes the page, I can easily see if they are still authenticated and if not, boot them back to the login page.
But #1 keeps things easy in the sense that the frontend server deals with just that: the frontend stuff.
Does any suggest one method over another? Why?
Does anyone have any other alternatives?
Thanks all!
You're reinventing the wheel by doing using an access_token. Devise already generates a cookie and sends it back when signing in. Just parse this cookie out when the client logs in:
User logs in with backbone app (post request is sent to API server)
Devise does it's thing and authenticates the user, generates the session_id and sends it back in an HTTP Set-cookie header.
backbone app parses the cookie out and caches the session_id value (think of this as your access_token)
each subsequent api call sends the cookie value in an HTTP Cookies header as session_id=cookie-value-here
Note your session cookie name is custom to your app and can be configured in an initializer via:
# /config/initializers/session_store.rb
YourRailsApp:Application.config.session_store :cookie_store, :key => '_your_rails_app_session'
I own both, an API backend at api.example.com and a frontend single page app at example.com . The API is basically a wrapper for a database backend.
Now, I want to have a user of the single page app (= client app) to authenticate with the API. For this, as far as I understand, the client (= single page app) sends a client_id together with a user_id to the API, and the API then gives out an AccessToken.
However, in my single page app, I am not sure where/how to store the access token. I am looking for a simple reference, or a good concept to have a logged in user access the API application.
A friend suggested me this flow:
The client displays inputs for login (be it e-mail or username) and password,
The client app makes a request to your API to obtain an unauthorized token (e.g. POST /api/v1/auth/new),
The server creates a token for the app and sends it back,
The client app sends the token along with the login, password and request signature to the API (e.g. POST /api/v1/mobile_authenticate),
The API validates and verifies the credentials,
If everything is OK the app uses the token to make further on the user's behalf.
Any thoughts? How can this be simplified or improved?
I'm using the api key for the permission check in the server API. The workflow how the api key works is as below.
The client app displays inputs for login (be it e-mail or username) and
password.
The client app makes a request to the API to obtain an
api key (e.g. POST /api/v1/users/validate).
The client app accesses the API with the api key. (If it is the http request, the api key can be included in the http header or query string.)
Hope it helps.