I am using Microsoft Bot Framework to build a bot that receives messages from a user and then connects to a a banking service he already registered. (In case you don't know Bot Framework, is just a Web Api where you post messages and it answers you according to the behaviour you specified in advance).
So the banking service knows his user and password. And let's say it also knows the user Skype's username, because the bot will be connected to a Skype Channel via Bot Framework Connector.
My question is: how can I authenticate (in the banking service) the user that sending messages to the bot? The idea of this is of course not to make the user send his credentials (user and password) via messages.
Making the bot send a link where the user can write his credentials and then trigger a callback is not an option. I need to make the authorization flow the most transparent I could do it for the user.
The only examples I currently have of Auth involve invoking a browser for the authenticating service where the user can enter their service-specific credentials, such as Mat Velloso's AuthBot sample on github: https://github.com/matvelloso/authbot
I assume your last statement means this isn't a valid option?
Related
Overall flow
I'm working with Google Cloud Platform (GCP), Google Apps Script (GAS), and the Pub/Sub service within a Google Workspace domain environment. This is the flow of requests/data, which works but clearly has auth issues:
GCP Pub/Sub service receives messages for a specific topic
Pub/Sub forwards the message to a push endpoint URL by POST
The push endpoint is a doPost() function within Google Apps Script (GAS), published as a Web App
Details
I have enabled authentication for the Service Account used in the Pub/Sub delivery type options, i.e. Pub/Sub signs a JSON Web Token (JWT) and sends the JWT in the authorization header of the push request. Edit: The Service Account (Client ID) has a domain-wide delegation for the Scopes
https://mail.google.com/
https://www.googleapis.com/auth/drive.scripts
https://www.googleapis.com/auth/drive
Web App deployments come with two options:
"Execute as"
Me (name#workspace-domain.tld)
User accessing the web app
"Who has access"
Only myself
Anyone within {workspace domain}
Anyone with Google account
Anyone
Right now, the web app executes as Me with Anyone having access. And it works.
Problems
The push endpoint is publicly accessible, but should not be. (1)
Follow-up: "The push endpoint must be a publicly accessible HTTPS address" (source) anyways, so "Who has access" will be set to "Anyone" by design.
Limiting the "Who has access" option to "anyone within {domain}" leads to unacknowledged messages inside the Pub/Sub subscription, doPost() will not run, but the endpoint returns straight 40X HTTP codes (probably forbidden).
--> Question: How can I promote the Service Account to being seen as a user within the workspace domain, so it has access to the endpoint?
The push endpoint should validate tokens sent by Pub/Sub. (2)
In GAS, doPost() has no access to (authorization) headers sent to the web app endpoint URL (unfortunately and as far as I know). However, ScriptApp.getIdentityToken() gets an OpenID Connect identity token for the effective user, if the openid scope has been granted.
--> If problem (1) was solved, is it possible to authenticate and authorize the messages send to the endpoint within the GAS doPost() function using ScriptApp.getIdentityToken()? From my understanding, the Service Account should also become the effective user, i.e. "Execute as" = "User accessing the web app".
I might be missing something. So, thanks for any tips and advice!
Doc links
Google Apps Script: Web Apps
https://developers.google.com/apps-script/guides/web
GAS: ScriptApp.getIdentityToken()
https://developers.google.com/apps-script/reference/script/script-app#getidentitytoken
Using push subscriptions: Authentication and authorization by the push endpoint
https://cloud.google.com/pubsub/docs/push#authentication_and_authorization_by_the_push_endpoint
We have a mobile application and end users are authenticated via Firebase.
Current behaviour
While onboarding users, we register every user on Firebase with an email and a mobile phone.
Once the user is created on Firebase we the use the link generation API generateSignInWithEmailLink and send an email to the users.
Users click on the email from their mobile phone and it automatically launches the App.
Desired behaviour
Instead of sending an authentication link in the email, we would like to use the SMS token validation feature of Firebase
This is very easily down via a browser based application.
How do we implement such a feature that on Android/Ios?
Option
We provide a custom backend HTTP end point which gets called by the user
From this backend, we instruct the Firebase Admin SDK to send a new SMS authentication token to the have any endpoint which allows the back end to send a SMS authentication token to the end user's mobile.
Is this possible? At first glance, I could not find anything in the documentation.
Thanks
https://firebase.google.com/docs/reference/admin/node/admin.auth.Auth
Firebase does not provide a generalized service for verification via SMS. You will have to find another service for that.
I'm working on a personal project composed of an API and 4 clients (web, android, iOS, windows phone).
I'm using django-rest-framework and oauth2 toolkit on the API side and I wonder which grant_type would be more suitable in my situation.
I read somewhere that the implicit grant_type is appropriate for working with mobile clients.
I'm currently using the resource owner password credentials system.
My current workflow is:
The user creates an account on the API registration page (http://mysite/api/register) then gets redirected on the web client.
The user have to authenticate himself on the API from the web client (the secret and client ID are store in the web client). If the authentication is successful the access_token and refresh_token are both stored in the user session.
Each time the user want to access a page I verify if he is authenticated by requesting the API using his access_token. If the request fails, I retry with the refresh_token. If it's fails again I redirect the user on the auth page.
The user can use the API on a mobile client with the same account without extra manipulations (the secret and client ID are store in a secure location ex. share preferences or keychain)
I like this workflow, it's simple and convenient for the user: he registers once and can use all the clients and I get a perfect separation between the logic (API) and the UI (client). But I'm worried about the security of this system. I don't want to expose my users to threats. Do you guys have any thoughts, recommendations, suggestions?
You help in this matters would be very appreciated.
Thanks in advance!
I am developing a BlackBerry application in which I need to use PUSH API. I already have registered with RIM and they have sent me the credentials for evaluation service. In my BlackBerry device, I installed sample push API application just to test that the push messaging works. After setting the content provider URL which is publicly accessible, I entered all the details for the sample application to register the it for receiving notification messages. When trying to register it asks for username and password but I don't know what they are for. In the email received from RIM, there are passwords for server application and content provider admin portal applications but not for the push client.
When I added an arbitrary username and password it fails with the message that java.lang.Exception Registration with Push API failed, caused by port is unavailable. But when I unregister it successfully unregisters the user with the given arbitrary username and password. By the I use the port given in the RIM's email.
I have no idea why this happens and I appreciate immediate response from you. Thank you.
The first thing to point out is that the RIM sample push application is ridiculously overcomplicated. The username and password you are referring to are used to authenticate against the sample push initiator web application which runs on your tomcat server. It doesn't matter what you put in there, they are not used for authentication. I can only assume they were added to show you that you can send a username and password to a web based service.
The only things you need in your BlackBerry app to register for the push service are:
Push Application ID (e.g. 2672-c870l6c924r1i298O4o33cc5391y0e75134)
Push Port (e.g. 31940)
BlackBerry Push Server URL (e.g. http://pushapi.eval.blackberry.com)
The port is unavailable message you're receiving is probably because the device you're using has not been provisioned for BlackBerry Internet Services (BIS). Make sure it has a SIM with an active BlackBerry data plan.
I have developed a simple API to allow communication between my Android/iPhone apps and my server. In my application, users need to authenticate themselves and they do it using login/password credentials with the following API call:
http://api.myapp.com/login?user=xxx&pass=pass
Application receives in return:
{ "api_token": "xxxx-xxxx-xxxx-xxxx" }
So basically I exchange my credentials against api_token.
I would like to add Facebook connect support. I have successfully used the Facebook SDK and receives the correct access_token.
However, I need to implement a mechanism to exchange access_token with api_token
Assuming the user has already connected his account with Facebook (on his web user panel), what would be the best implementation to proceed to the exchange?
Here is how I finally did it. It's working very well for more than one year, never had any problem. The idea is to exchange tokens using the following API call:
http://api.myapp.com/login/facebook?access_token=<facebook_access_token>
Server side, you verify validity of the access_token with a simple
wget -qO- https://graph.facebook.com/me?access_token=<facebook_access_token>
Which sends you back a JSON with all user information, including user's Facebook ID. Assuming the user has already connected his account to Facebook, you can lookup the user_id and send back an api_token.
http://developers.facebook.com/docs/authentication/
The best implementation will naturally depend upon your current platform. There are several Ruby on Rails gems, for example, that handle to whole Open Authentication bit for you.