Results 1 to 6 of 6

Thread: Gmail oAuth: Blijft dat werken of moet je naar REST?

  1. #1
    Senior Member
    Join Date
    Jan 2002
    Location
    Nieuwlande, Nederland
    Posts
    604

    Gmail oAuth: Blijft dat werken of moet je naar REST?

    Beste lezer,

    Waarschijnlijk een onduidelijke titel in de verkeerde rubriek.. maar toch:

    GMail stopt op 31 mei aanstaande met ondersteuning voor "minder beveiligde applicaties" -> inloggen met naam en wachtwoord.

    De meeste componentenbouwers en mijn opdrachtgever gaan uit van toegang tot Gmail via REST API. M.a.w. dat gebruik van Imap/Pop/SMTP niet meer mogelijk zou zijn vanuit eigen software na 1 juni aanstaande.
    Maar ik heb op https://github.com/geoffsmith82/GmailAuthSMTP een voorbeeld gevonden wat gewoon met Indy werkt en ik heb bovendien sterk de indruk dat het GMail gaat om oAuth authenticatie.

    Ik kan alleen nergens met zoveel woorden vinden dat oAuth gewoon werkt en blijft werken. Wat ik wl heb gezien is dat Google spreekt over werken met industrie standaarden en dat REST voor light-weight toepassingen is.

    Wie kan me in de richting wijzen?

    Dank alvast!

  2. #2
    Quote Originally Posted by Teo View Post
    GMail stopt op 31 mei aanstaande met ondersteuning voor "minder beveiligde applicaties" -> inloggen met naam en wachtwoord.
    Ik weet niet waar je dat gelezen hebt maar ik neem aan dat dat niet opgaat voor de gewone App-wachtwoorden.
    Dus je zou dan gewoon nog steeds een App-wachtwoord aan kunnen maken en mail via SMTP kunnen verzenden.

    Het gebruik van de instelling "minder beveiligde app" i.c.m. je e-mail en eigen wachtwoord (was nog mogelijk via instelling) zou dan niet meer mogelijk zijn.

    Mogelijkheden zijn dan dus:
    *) direct via API een EML/Json versturen met OAuth2
    *) via IMAP versturen met OAuth2
    *) en dus met App-wachtwoord via SMTP versturen (zonder OAuth2)

    Ik meende dat het tegenwoordig ook verplicht is een toestemmings-procedure te doorlopen voor OAuth2 (tenminste dat moest ik een tijdje geleden).

    Let op: Die laatste is dus wat anders dan de "Less Secure Apps" optie die per 30 mei niet meer kan.

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Location
    Nieuwlande, Nederland
    Posts
    604
    Dank je Rik,

    Ik doel inderdaad op de "Less Secure Apps" optie. En ik maak uit jouw antwoord op dat jouw code met Synapse en de code van Geoffrey met IMAP/SMTP beide werken.
    Heb jij die code nog aangepast naar Indy zoals ik meende te lezen?

    En is het dan niet simpeler om de IMAP/SMTP optie te kiezen boven direct via de API sturen?

    Groet,
    Teo

  4. #4
    Quote Originally Posted by Teo View Post
    Heb jij die code nog aangepast naar Indy zoals ik meende te lezen?
    Nee, ik gebruik uitsluitend Synapse in mijn programma.

    Ik heb beide methodes
    Voor GMail API stuur ik een concept naar https://gmail.googleapis.com/upload/gmail/v1/users/<username>/drafts die ik daarna direct open in een browser zodat de gebruiker de draft nog kan controleren/wijzigen en dan versturen.
    Voor GMail IMAP doe ik hetzelfde om via TIMAPSend van Synapse een concept op te slaan en daarna te openen.

    Voor de GMail IMAP moest ik de TIMAPSend wel aanpassen/hacken om ook een AUTHENTICATE XOAUTH2 te kunnen versturen. Nodig om aan OAuth2 te voldoen.
    Dat is bij GMail API uiteraard niet nodig. Ik weet eigenlijk niet of het mogelijk is om met een App-password de IMAP te benaderen (moet ik eens proberen ).

    Voor beide methodes zijn dus wel een OAuth2 nodig om een access_token te krijgen (via een eenmalig toestemmingsscherm aan de gebruiker).
    Ik moest voor het authenticatie scherm een toestemmingsprocedure doorlopen (tot het maken van screenshots en filmpje toe).

    De GMail SMTP optie gebruik ik zelf niet omdat hierbij de mail direct verzonden wordt. En vanuit mijn programma moeten de gebruikers de mail nog aan kunnen passen. Dit zou natuurlijk via een eigen dialoog/verzendscherm kunnen maar ik wilde gewoon de standaard methode gebruiken zoals de gebruikers zelf gewend zijn (dus vanuit hun eigen mail programma). Voor Outlook, Thunderbird, EML-handler, GMail IMAP, GMail API, Office365 API en Classic Windows MAPI heb ik dus allemaal procedures.

    Als je dus al code hebt om via een SMTP server te verzenden, en je vindt het niet erg dat de gebruiker zelf een eigen App-password moet aanmaken en invullen, dan is dat de makkelijkste methode. De OAuth2 methodes (API en IMAP) zijn dus een stuk uitgebreider.

  5. #5
    Het probleem met applicaties die je username en wachtwoord willen hebben, is dat ze dan je username en wachtwoord hebben. Logisch he

    oAuth(2) is een standaard, waarbij de app of applicatie een webpagina (van Google) kan laten zien om in te loggen. Je ziet dan dus een inlogschermpje in de trant van "DieEneApp will toegang om dit en dat te kunnen doen", je logt in, en je app krijgt een token waarmee hij kan zien dat inderdaad een bepaalde persoon is ingelogd, en waarmee de app eventueel bepaalde dingen kan doen met je account, zonder je wachtwoord te krijgen.

    In die token kan bovendien allerlei meta-informatie zitten, over tot wanner hij geldig is, wat er allemaal wel en niet mee mag, enz. Zo kan je een app maken die wel je adresboek kan inzien, maar niets verwijderen, niet mailen, niet je mail lezen etc. Of zelf een app die helemaal niets van je account kan zien, behalve wat basisgegevens om te zien of jij inderdaad persoon X bent.

    Die standaard is inmiddels zo ver, dat ook Google's eigen systemen, op een enkele uitzondering na, op die manier werken. Je hebt dus een Google account, en daarmee log je in in je Google Mail, je Google Drive en je Google Agenda. Je Google Agenda weet dus waarschijnlijk niet eens het wachtwoord, maar gebruikt ook zo'n token om te valideren of jij jij wel bent.

    Al met al is dat een stuk veiliger, omdat je wachtwoord alleen bekend is (als hash tenminste), bij die "identity provider", je veel meer controle hebt over wat een app wel en niet kan, en je die toegang ook op elk moment weer in kan trekken.

    oAuth is overigens een standaard over hoe die berichtgeving heen en weer werkt. En meestal gaat dat 'gewoon' via een REST API, al staat dat in feite los van elkaar, net zoals REST meestal, maar ook niet noodzakelijk over HTTP werkt.

    oAuth2 is op dit moment d standaard, en ik zie nergens aanwijzingen dat Google of andere partijen overwegen om ermee te stoppen.
    1+1=b

  6. #6
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,739
    Ik heb gisteren net een project afgeleverd met oAuth(2). Niet met indy, maar met EASendmail. Indy willen we uitfaseren.
    Delphi is great. Lazarus is more powerfull

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •