We have API fro web and mobile application. authentication is with oAuth2,
now we need to add sip functionality to application an I am wondering if its possible to not store user passwords on client side and send to asterisk only access token of logged in user.
asterisk will in background send request to our API and our api will response user is valid or not.
this scheme works fine with ejabberd server but I cannot find anything like this in asterist.
Sip standart support only md5sum authentification and password.
However if you are developing both part(client and server) you are free to rewrite authentification function. Asterisk is opensource soft, it alow that(c/c++ coding required).
Without C such functionality can be done on kamailio/opensips.
You also can allow guest calls on asterisk and do auth in dialplan, using any method including func_CURL.
Related
I have a web app that exposes an api using devise_token_auth. I build multiple mobile apps that talk to different facets of this web app over https. They use devise_token_auth to get an access token, and then the access token is used in future requests.
I want to avoid the case where others create their own mobile apps that talk to my web backend.
When a call is made from the mobile client, it uses a user and password who has already signed up on my server to get an access token. How do I preclude others from creating their own mobile clients?
Option 1: I could create a secret api token, and use it on the client and server, where mobile client passes in the api token and the server only accepts the requests containing the api token.
Problem with option 1: anyone who sees the request on the wire can now create a similar request with the api token, and use the api token to make the same call.
Option 2: I make my web server an oauth server, where my app uses oauth to authorize client requests only for my own api user, and rejects other requests.
Problem with option 2: I don't know enough about oauth to know if it works this way, and how to implement this in addition to devise_token_auth - this effectively means two credentials are checked on the server - the oauth verification of the api user, and the devise_token_auth verification of the actual user.
I did look at this and this related questions, but they are not exactly my scenario. The recommendation in those threads seems to be a) that https + basic auth is enough and oauth is unnecessary, and b) blocking ip addresses that are unauthorized (Problem: I don't know how to detect which ip address is my mobile app users' and which is someone else's). c) Another insight from those threads is that if I stored some private secret key in my mobile apps to use to identify the app, they are likely going to be exposed since mobile apps (at least on android) are fully reverse-engineerable.
Any suggestions on how best to design/implement this? Is just https + basic auth sufficient?
I would be happy to share any code (since SO usually expects code in the question) - but honestly don't know what code to share here.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.
I'm working on an command line utility that requires access to a backend server over a REST API.
I'm trying to avoid implementing my own authentication mechanism and use one (or more) of the public auth services (like google, Facebook, amazon).
I am trying to make the client accept credentials and authenticate against the authentication provider and do that without asking the user go open a web browser and provide back a token. The client will be open sourced in order to avoid trust issues (i.e. the user credentials are not sent to my backend server).
I am not interested in authorization, I only care of authenticating against my backend server without having the user keep yet another set of credentials (and without sending the user credentials to my backend server).
How can I have my client authenticate with the auth provider and get a token to communicate back with my server without having the user use a web browser?
I realize you said "not open a web browser", but what about if that browser is on another device (e.g. their mobile?).
If that is acceptable, you can use the OAuth 2.0 for Devices approach, whereby you present the user a short alphanumeric code, which they enter on http://google.com/device to authenticate the request from another device. This OAuth flow is designed to work in environments which don't have browsers (like a command line).
To see a demo of this authentication flow in action, visit the YouTube TV site, press the ← key on your keyboard, and select Sign In.
It's also easy to try out yourself – create a OAuth client in the developers console (of type "installed application" -> "other"), and follow the curl examples in the docs (be sure to replace the demo code in the token request with the device_code received from the initial request to the code endpoint). Decode the resulting id_token using any of the example JWT decoders, like this one.
In your case, you should request the profile scope, which will return an id_token in the response to your token endpoint call, from which you can extract the user's Google profile id (the id token's sub field).
For my current work project we're trying to use OAuth to secure a mobile API, but the app doesn't have user accounts, so authentication would take place invisibly from the user, where the app will send up some secrets to the server and receive the token to be used for subsequent web service calls. The problem is, all the libraries and tutorials I can find implementing OAuth follow this pattern:
Present a web view allowing a user to login
Receive a callback to a custom URL scheme, and parse the necessary information to authenticate future web service calls
How do I achieve this without the webview step? I should be able to make an HTTP request directly with the correct credentials which will return the necessary authentication details.
The app will use OAuth 2.0
It is not clear what do you mean by
the app doesn't have user accounts
If you want to call some API on behalf of user you should ask him for a password. Doing it in webview or not depends on provider implementation. For example, twitter doesn't force you to do that.
In other case, if you want to call service on behalf of client, take a look at this answer: https://stackoverflow.com/a/7477112/2283405
If the app doesn't require "personalised" or "user-specific" data to be manipulated, then you can probably try using "client-credentials" grant type to obtain access tokens using the application credentials granted upon the application registration process by the Authorisation Server (for e.g.: OAuth server) that's there in your environment. The idea is that, your app is what basically authenticates with the Authentication Server for you using the aforesaid credentials (i.e. Client Consumer Key and Client Secret Key).
NO, you have to do login compalsary. if you try without. it won't be possible.
I have a webapp which does a lot of ajax requests with the php server and database server. I have also created an iPhone app and an Android app, which have been working as offline apps till now.
Now I want to create an API which will be used to sync data between web server and smartphone apps. Should I be using OAuth for this? What I have read about OAuth - it seems like it is used if I want to open my API to be used by third party apps. But here I just want to ensure secure transfer of data between API and my own apps.
Can somebody shed some light on this?
The main usage of OAuth is to make third-party apps authorized to access private resources of a user on a website without giving user credentials to the third-party app. For example, suppose that Twitter wants to get the list of contacts from your Yahoo account. The traditional way is to give your username and password to Twitter. But with OAuth, you give them a temporary token (called Access Token) which authorizes Twitter to access your contacts on Yahoo for a limited amount of time (until either this token expires or you, as the owner of private resource, explicitly revoke it).
That said, OAuth is not about securely transmitting data on the web. That's another story which is usually achieved using SSL. Even when you use OAuth, you have to use SSL alongside to make sure data is sent and received securely.
So in your case, you have to see what the API is used for. If it's public API which doesn't give any private data to the callers, there is no need to use OAuth. If the API is for accessing private resources of individual users however, You may consider using OAuth. If you opt to implement OAuth, you may allow other third-party apps to access your API in future without any concern.
Well a lot depends on how you are securing your API. Is your API open to public specially the post urls? If your data is not something which every user should see, then how are you checking the authentication of the user credentials?
Most the important thing is that we should avoid sharing the username and password over the wire to check for authentication all the time. This means, your API should not require username and password to validate if the user is valid. Which you can do by sending the username and password from mobile or device id or some other thing.
In such situation, the OAuth server comes to the rescue. Basically, on one URL a user will send his username and password to get his access token. Once that is acquired, we can use the access token to validate each request and take necessary actions.
You can refer the videos where I have implemented OAuth server in Laravel 5 using bshaffer which is one of the best OAuth library for any PHP framework to user. https://www.youtube.com/watch?v=0vGXbWdtjls