Many mobile apps require user login. That's why Ionic launched their Auth service (https://docs.ionic.io/services/auth/). I can create users via the Auth service itself or via the Ionic API. I also can save custom data for each user. Very nice is also that I can sen targeted push notifications to my users. Seems like a nice out-of-the-box solution.
But most of the time apps have more complex logic (user can post something, user can order something, make a payment, ...). The simple user with some atributes from Ionic does not help much in those cases.
So I need to authorize the users not only inside the app but also against some custom API. And this is where my questions come up...what's the best way to do this?
Some things that came to my mind:
When creating the user in Ionic, also create the same user with the same email and password in my API. So I can make authorized requests. But this does not user any token and I would have to pass my password in every request, also I am worried about data consistency. What if the user changes its password?
Use the internal Ionic user ID, create one global token and use user ID and global token to authenticate the user in my API. But is this secure?
Another worry in my mind: If I save user name, email etc in the Ionic Auth system I would have to access it via their API every time I need it in my own system. For example: A user orders a product in the app. Then my system needs to send out a confirmation to the user. I would have to access the Ionic API to know that users email...and so own.
I think this is all confusing.
Is Ionic Auth not made for those situation? Then, I don't see what it's made for at all...
Is ionic Auth just not there yet...?
Am I just not getting it?
Related
I'm creating an OIDC provider with oidc-provider. For now, my Registration flow required email verification step, which is handler outside oidc-provider. This approach works but it leads to an issue that user can not automatically login after setting up their password.
I thinking of creating a new prompt policy name email-verification, something like:
https://<auth-endpoint>?client_id=...&prompt=email-verification
I wonder:
Is this flow acceptable with OpenID Connect specs?
Is there any document, tutorial or example in terms of specs or implementations of this approach?
The case user register in mobile app, but open email link in web (we have a mobile app with different client_id and of course, different redirect_uri. What should we redirect user to the app without error.
Thanks,
I want only people whom I register or with specified email should be able to use google sign in, rest are not allow to sign in.
example:- I run a institution and I have separate id for my fellow students and I want them to only be able to sign in using that id and otherwise they should not be allowed to use any other Id(email to be more precise).
in my flutter application using firebase-> google_sign_in.
hope I am clear!
bro add some g mails in your firestore those people you want they can access my app if this emails exist in your db then they can google signin otherwise show toast your account is not regirsted by admin
try{
FirbaseFirestore.instance.collection("alloweduser).doc().where("emial",isequalto:123#gmail.com).then(){
Goolglesinin()
{
google signcode
}
}.catch(e)
{
showToast("ask admin to app permission")
}
You are talking about authentication vs. authorization.
Authentication: Since google is your authentication provider... anyone with a valid google account is authenticated.
Authorization: Who has access to what parts of the application?
You need to implement an authorization system / flow to determine if an authenticated user has access to the app. By default... all users will have NO ACCESS.
How you implement authorization - depends on your backend and how you store user data. If you are using firebase, something like this will help: https://firebase.google.com/docs/firestore/solutions/role-based-access
Am a bit confused about the One tap sign in that was announced by google earlier this year. Our application already users Credential Management API in Chrome, which essentially provides the user with login options based on the credentials that user has saved for our site on previous visit (passwords that are saved in chrome). When I read the documentation for One tap sign in, it promises to do the same thing, but using Google's client api id. Our application has its own ID provider with our own database of user name and passwords, from the documentation it looks like One Tap sign in does not support custom ID providers. Can anyone shed more light on this, why would I use one against the other?
Thanks
Karthik
I see two major differences:
One Tap is passwordless - it uses a token based login that never exposes the user's password. Chrome Credential Management API stores and retrieves actual passwords in Chrome's password store.
One Tap is purely web based - Chrome Credential Management API relies on Chrome's specific implementation. One Tap is a purely web based workflow so it will work across browsers.
One Tap is a much better long term login solution in my opinion. The Credential Management API is experimental and currently only supported in Chrome.
https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility
I lead product development at Google for the one-tap/auto sign-in library, we designed it such that the library includes the Credential Management API and extends to provide assistance in account creation, secure passwordless, and cross-browsers support.
In particular, if you make a request for existing credentials with code like this:
googleyolo.retrieve({
supportedAuthMethods: [
"https://accounts.google.com",
"googleyolo://id-and-password"
],
supportedIdTokenProviders: [
{ uri: "https://accounts.google.com", clientId: "CLIENT_ID" }
]
});
then any saved username/passwords from the Credential Management API will be returned (in browsers supporting the API) along with token data for Google Accounts. The one-tap/auto sign-in JavaScript library wraps the Credential Management API for credential retrieval.
Furthermore, the library provides a googleyolo.hint method to show an email selector for one-tap selection of a verified email address to assist in new account creation, or to link to an existing account, and then be auto signed-in next time with token instead of password, across all browsers, so long as the same Google Account is active.
I'd suggest using the one-tap/auto sign-in library and consuming tokens as well as passwords in order to get assisted sign-up, keep existing users signed-in automatically, and provide functionality even if the browser does not support the Credential Management API.
As for the question about using your own database of username / password, the hope with this library is you could implement the ability to create accounts and auto sign-in to these and existing accounts with an OpenID Connect ID tokens representing the user's identity. With the one-tap / auto sign-in UX, these are not only much more usable, but far more secure then passwords and mitigate creation of weak/re-used passwords. Please consider this or, even better, a hosted auth solution like Firebase Auth or Auth0 and include the one-tap UX in the frontend UI.
Since LinkedIn discontinued their network updates RSS feeds, I haven't been able to find any "simple" mechanism to gain access to update feeds w/o going through the oauth process requiring the user to authenticate first. The few examples I've seen posted here all assume you've obtained the auth token first. Is that even possible?
In case anyone else inquires: https://developer.linkedin.com/support/faq
If your application requires you to make API calls in an automated way
- without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your
application refreshes the token automatically prior to expiry to avoid
the need for additional human authentication.
I've been reading a lot about the topic but all I find are obsolete or partial answers, which don't really help me that much and actually just confused me more.
I'm writing a Rest API (Node+Express+MongoDB) that is accessed by a web app (hosted on the same domain than the API) and an Android app.
I want the API to be accessed only by my applications and only by authorized users.
I also want the users to be able to signup and login only using their Facebook account, and I need to be able to access some basic info like name, profile pic and email.
A possible scenario that I have in mind is:
The user logs-in on the web app using Facebook, the app is granted
permission to access the user Facebook information and receives an
access token.
The web app asks the API to confirm that this user
is actually registered on our system, sending the email and the
token received by Facebook.
The API verifies that the user
exists, it stores into the DB (or Redis) the username, the token and
a timestamp and then goes back to the client app.
Each time the
client app hits one of the API endpoint, it will have to provide the
username and the token, other than other info.
The API each time
verifies that the provided pair username/token matches the most
recent pair username/token stored into the DB (using the timestamp
to order), and that no more than 1 hour has passed since we stored
these info (again using the timestamp). If that's the case, the API
will process the request, otherwise will issue a 401 Unauthorized
response.
Does this make sense?
Does this approach have any macroscopic security hole that I'm missing?
One problem I see using MongoDB to store these info is that the collection will quickly become bloated with old tokens.
In this sense I think it would be best to use Redis with an expire policy of 1 hour so that old info will be automatically removed by Redis.
I think the better solution would be this:
Login via Facebook
Pass the Facebook AccessToken to the server (over SSL for the
android app, and for the web app just have it redirect to an API endpoint
after FB login)
Check the fb_access_token given, make sure its valid. Get user_id,email and cross-reference this with existing users to
see if its a new or old one.
Now, create a random, separate api_access_token that you give back to the webapp and android app. If you need Facebook for
anything other than login, store that fb_access_token and in your
DB associate it with the new api_access_token and your user_id.
For every call hereafter, send api_access_token to authenticate it. If you need the fb_access_token for getting more info, you can
do so by retrieving it from the DB.
In summary: Whenever you can, avoid passing the fb_access_token. If the api_access_token is compromised, you have more control to see who the attacker is, what they're doing etc than if they were to get ahold of the fb_access_token. You also have more control over settings an expiration date, extending fb_access_tokens, etc
Just make sure whenever you pass a access_token of any sort via HTTP, use SSL.
I know I'm late to the party, but I'd like to add a visual representation of this process as I'm dealing with this problem right now (specifically in dealing with the communication between the mobile app and the web api by securing it with a 3rd party provider like facebook).
For simplicity, I haven't included error checks, this is mostly just to outline a reasonable approach. Also for simplicity, I haven't included Tommy's suggestion to only pass your own custom api token once the authorization flow is over, although I agree that this is probably a good approach.
Please feel free to criticize this approach though, and I'll update as necessary.
Also, in this scenario, "My App" refers to a mobile application.