Comments (10)
The same principle applies to accessing ISP controlled mail servers (e.g. Comcast) and other smaller regional players, though.
Anyway, it sounds like we're all in agreement that we can drop this feature from the spec for the implementor's draft, and reintroduce it later with specific treatment if desired.
from openyolo-android.
@smarkovik and @StanKocken were the originators of this idea, it would be good to hear their perspective. I think I support removing this for the initial release and more carefully think about the use cases for "masquerading" as another app for credential retrieval. The most prominent use case (keyboard integration) should have no UI, so that may actually deserve it's own API methods for direct credential retrieval.
from openyolo-android.
At last some chatter on openYolo. I must say it's refreshing to reply on a thread in this repo.
I believe this is quite an important feature in a final api, as it would allow any app to request any credential, which is the sole purpose of a credential manager To manage your credentials. like any browser can open any protocol (ftp, file etc.. ), not only http/s.
True, the. usage is a bit of an edge case, if you're thinking of Google, facebook twitter and linkedin, as they're the BIG authentication domains. which provide a clear entry point however if you think about the wider use case, like, zoom requires my company account to work, same with outlook, even gmail, may reqiure a non-gmail credential to work. So it's an edge case in the Big world but out of 200+ which i have in my account only 10 of them are in the Google Facebook etc. list.
however, I also agree this is a feature we can surely postpone for a future release. Even more to the point, you don't all have to share my opinion, and if everyone here thinks it's obsolete or not required I would agree as there needs to be consensus.
So in short, I am all in favor of postponing it, but I believe it's a feature which has merit.
your thoughts?
from openyolo-android.
A concret example can be a third-party app like Tinder. You can (at least was the case few years ago) use only a Facebook credential. What to do in this case? Tell the developers of this app "you cannot use OpenYolo" or we have to find an alternative solution.
I'm good with the first answer for now, maybe think about the second later?
The way we wanted to do that, as a Password Manager, was to say "This is not the Facebook app, are you sure to provide your Facebook credential".
from openyolo-android.
I think the case you describe for Tinder is actually OK - Tinder can request a credential hint, and specify that it supports Facebook as an authentication method. The user can then select their Facebook account from the hint list, and Tinder uses this hint to begin Facebook authorization for that account. If authorization succeeds, Tinder saves a credential with authentication method "https://www.facebook.com" for future retrieval.
The scope of what @dxslly is discussing is the ability to ask for saved credentials for other apps and domains. The use case I remember discussing with @smarkovik was for an email app to be able to ask for the ID and password for your Google account in order to automatically configure POP3 / SMTP. It is currently the responsibility of the credential provider to decide what to do with such a request:
-
The provider must correctly identify that the app does not belong to the Google authentication domain equivalence class. This shouldn't be too difficult, using Digital Asset Links, but it's a likely source of security critical bugs.
-
The provider must decide what to do with such a request. In the Smart Lock for Passwords implementation, we ignore any requests for credentials from authentication domains the app is not provably associated to. Others may instead with to display a picker with a modified, scarier prompt to try and make sure the user understands what they are consenting to.
Both steps are a cause for concern, which is why I think that more careful consideration of this feature is required. A different API method for this case, with much more clearly defined semantics, may be better.
from openyolo-android.
I would also be in favour of a cautious approach here. The example of providing Google credentials to an email app definitely highlights an edge-case that users and third-party apps might want supported. Whether it should be supported is something that I think warrants more discussion though, for the reasons that @dxslly and @iainmcgin have highlighted above. With that in mind, I would be happy to see support for requesting disjoint authentication domains removed for now.
from openyolo-android.
from openyolo-android.
"The example of providing Google credentials to an email app definitely highlights an edge case"
Actually there is nothing the email app can do with your Google password, we don't allow IMAP authentication via Google passwords (anymore). Such apps need to use OAuth (via OAuth for Native Apps).
from openyolo-android.
For reference it is RFC7628 in combination with Oauth best practices for native apps https://tools.ietf.org/html/draft-ietf-oauth-native-apps (AppAuth is the OIDF SDK name).
Email apps taking passwords is one of the largest security threats we have as it stops people from being able to do multifactor everyware.
Microsoft and apple have proprietary versions of RFC7628 that they support. It would be good to move email apps on to the newer model where they would query for a hint and use that to do OAuth to Google or other Mail provider to get a access token for IMAP/SMTP.
That is the pattern that I prefer to promote.
from openyolo-android.
Code changes to finalize this made in #11.
from openyolo-android.
Related Issues (20)
- Document interactions with Android O's Autofill HOT 15
- CredentialClient.getDeleteResult() should be getCredentialDeleteResult()
- Gradle Error when following the getting started guide when using Android Studio 2.x HOT 1
- Potential security vulnerability in passing Intents via BBQ HOT 6
- Remove backwards compatibility with old BBQ retrieve Intents HOT 2
- Cleanup: utilize ProviderResolver in CredentialClient
- Feedback on demo app HOT 5
- Library uses Java 8 which makes integration difficult HOT 4
- Android Studio auto complete shows Protobuf package too HOT 2
- Proguard exclusion is too broad HOT 2
- Demo app is not working as intended HOT 2
- Confusing behaviuor or bug in providers? HOT 6
- Helper method to find out is any supported provider available? HOT 3
- Test app OpenYOLO Get credential button not working HOT 1
- Tapping the provider picker quickly after it is shown causes it to be dismissed HOT 1
- Crash due to IncompatibleClassChangeError: org.hamcrest.core.IsNull HOT 2
- Crash java.lang.ExceptionInInitializerError HOT 1
- RuntimeException in sample code HOT 1
- Can't delete credentials in Google Smart Lock HOT 1
- Unknown retrieve response in Test app HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openyolo-android.