I have a web application with e.g 1...n users. User(s) logs in use application and logs out.
Now How to achieve if a logged in user say User "A" want to video chat with User "B"?
Does WebRTC shares a sessionId etc to identify which user is sending request and how this request is for specific set of users (Receivers would be only "B" User) ?
No, WebRTC does not provide this kind of authorization. That's because WebRTC relies on an external signaling system.
This kind of authorization you must include it in your signaling system. E.g. if you're using websockets you can use the session from there to authorize, identify and route the message to the appropriate user. And that will depend of course on what platform/technology you're using on the server side.
Related
I'm building an Identity Data Provider (IDP) to centralize my users' accounts and provide them with Single Sign On (SSO).
The goal is to allow our clients to navigate through our applications without having to reauthenticate and find their data back.
We built that central service with Laravel Passport. Authentication and SSO are working fine. Our applications retrieve users' data and store local user records for their own custom needs, filled with data from IDP.
But now, the question is : how should we keep local user records up-to-date with the IDP ?
We already set up a syncing mechanism driven by users' activity. But we'd like to go further and have a mechanism not based on user's activity. The goal is to be able to update an application local user on IDP data updates without having the user logging in the client app.
I can't imagine our central IDP sending requests to each application's API. I guess it's better being "one direction only", from client apps to IDP.
I was thinking about a "broadcasting" method based on websockets. The central IDP could send "user update" messages through a websocket. Clients apps could listen to this websocket and update their local records if needed.
What do you think about that ? Any experience feedbacks on that topic ?
Thanks for your help
Firebase admin is only available for admin or users also to send notification to other users?
Actually i am little bit confused in send notification from one user to another and which data is used like on the basis of user receiver uid or receiver fcm token.
firebaser here
Calls to the FCM API to send messages require that you specify the FCM server key in your code. As its name implies, this key should only be used in server-side code, or in an otherwise trusted environment. The reason for this is that anyone who has the FCM server key can send whatever message they want to all of your users.
So sending messages to users is indeed only possible from a trusted environment, either through the Admin SDK, or the REST APIs. See How to send one to one message using Firebase Messaging for more.
I am already using IDM together with Wilma PEP for access control to Orion.
Now I want to achieve the same for outgoing notificaitons.
Example:
I have an app with users which for example shows devices. The user logs in and authenticates with FIWARE IDM to access the Orion instance.
However, User A should only allowed be to access Device A and only get notifications for this Devices.
In Orion I have a subscription defined which triggers when any Device changes. Now an external system is updating the Device B.
I am currently having a notification endpoint (simple node js app) where the notification from the Device is passed back to the app via websocket.
Is there a way I can prevent sending the notification to User A? Is there a way I can check that notification with PEP and sending it only to the allowed users?
I was thinking of first passing the received auth token from the IDM with the websocket to check if the user is authorized. However, I still don't know how to check to which user I should send the notification. Is there a way I could pass the notificaiton request to the PEP proxy or any other solution?
I have an API with the following method:
https://api.example.com/services/dosomething
I am providing this service to three different mobile apps, each one with hundreds of users. When a user logs in in the mobile app, a call to my API needs to be made.
I know that providing each one of the three mobile apps a different API Key and doing a HTTP Basic Authentication with it is not secure, since the API Key would be unsafely stored in the device an anyone can take it and make bad use of it.
The approach of OAuth2 doesn't work, since I only have information of my three customers, not their hundreds of users.
What is the best approach to secure the calls to my API on mobile?
In your case, your approach with OAuth2 is good: mobile apps (clients) receive delegation from resource owners (your users) to call protected resources on a resource server (your API).
You only have information about your clients because OAuth2 is not dedicated to authentication of your users but authorization of you clients.
The clients are identified with a client ID. In your case and if you want to know which client calls your resource server, then each client should have a dedicated client ID. You may also identify it using other information such as the IP address or a custom header in the requests it sends.
If you want to know who your users are, you should implement the OpenID Connect extension. This extension works on top of an authorization server based on OAuth2.
The authentication of the user is performed by the authorization server. An ID Token is issued with information about the user. The client (or mobile app) does not have to get or store user's credentials.
There is an excellent video where the both protocols are explained (especially from 4:44 to 11:00).
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.