Today, there is an increasing demand for authentication services to provide authentication to users on the internet. One example of an authentication protocol is OpenID Connect. It is used by for example Google to provide single sign-on functionality to millions of users. Since this demand is growing and more companies are implementing the protocol, there is also a need to ensure that the protocol is implemented in such a way that ensures protection from adversaries attacking the services in different ways. This paper makes an effort at providing guidelines to those aiming at implementing the protocol. It looks into several attacks that can be performed. It is found that how one chooses to implement the protocol can greatly affect security and the protocol's susceptibility to attacks. The attacks that are studied are Cross Site Request Forgery (CSRF) attacks, Mix-Up attacks, Passive web attacks, and Distributed Denial of Service attacks. It is found, among other things, that implementers of the protocol should incorporate state variables to protect against CSRF attacks and services must utilize a secure HTTPS connection to protect e.g. sensitive data. A recommendation is made for how a federation with Relying Parties and OpenID Providers can be set up to further improve security.

Electronic identification is used by an individual to prove who he or she is by electronic means and is normally used for logging in to various services. In Sweden there are a number of different solutions that are developed and provided by different parties. In order to promote and coordinate electronic identification for public services, the Swedish E-identification Board was founded in 2011. The Board has developed a technical framework for integration between the Relying Party and the Identity Provider based on the Security Assertion Markup Language V2.0 (SAML) standard. SAML is a quite old standard that has some limitations complicating an electronic identification solution based on it. A newer competing standard is OpenID Connect, which could be a possible candidate as an alternative to SAML. The objective of this thesis is to determine to what extent it is possible to ensure confidentiality, integrity, and accountability in an electronic identification based on OpenID Connect. To achieve this, a number of requirements for electronic identifications were identified and a design proposal based on OpenID Connect was developed together with a proof-of-concept implementation. The design proposal was evaluated against the requirements, with the final result that an electronic identification based on OpenID Connect could meet the requirements. / E-legitimation används av en individ för visa vem han eller hon är på elektronisk väg och används vanligtvis för att logga in på olika tjänster. I Sverige finns ett antal olika lösningar som utvecklas och tillhandahålls av olika parter. För att främja och samordna elektronisk identifiering för offentliga tjänster grundades E-legitimationsnämnden 2011. Nämnden har tagit fram ett tekniskt ramverk för integrationen mellan Förlitande Part och Legitimeringstjänst baserad på Security Assertion Markup Language V2.0 (SAML) standarden. SAML är en relativt gammal standard med vissa begränsningar som komplicerar en e-legitimationslösning baserad på den. En nyare konkurrerande standard är OpenID Connect, vilket kan vara en möjlig kandidat som ett alternativ till SAML. Syftet med detta examensarbete är att undersöka i vilken utsträckning det är möjligt att säkerställa sekretess, integritet och ansvarsskyldighet för en e-legitimation baserad på OpenID Connect. För att uppnå detta, identifierades ett antal krav för e-legitimationer och ett designförslag baserat på OpenID Connect utvecklades tillsammans med en proof-of-concept implementation. Designförslaget utvärderades mot kraven, med det slutliga resultatet att en e-legitimation baserad på OpenID Connect kan uppfylla kraven.

The use of digital services has never been as important as it is today.It is possible to do everything from researching family history to banktransactions on the Internet. This creates a demand for secure servicesto ensure secure authentication of users. Electronic signatures havebecome an important part of e-identification over the last year due tothe the COVID-19 pandemic forcing many people to work remotely.OpenID Connect, or OIDC, is a framework that supports secureauthentication and authorization. But, it does not support electronicsignatures. The work done in this project has shown that an extensionof the OIDC framework is feasible for electronic signatures.A proof of concept has been built to analyse if an extension tothe OIDC framework was possible. The signature flow implementedis structured according to a proposal developed by an experiencedgroup of people working with e-identification. It extends the OIDCauthentication request with additional information to enable supportfor electronic signatures. The signature is done using BankID as an IDP.This work shows that it is possible to perform an electronic sig-nature, with an OpenID Connect authentication flow with signatureextension. The work has focuses on one model using an IDP thatperforms signing. An approach with a stand-alone signature service ispossible, but would be more complex for a limited proof of concept.

Federated Identity Management (FIM) and Single-Sign-On (SSO) concepts improve both productivity andsecurity for organizations by assigning the responsibility of user data management and authentication toone single central entity called identity provider, and consequently, the users have to maintain only oneset of credential to access resources at multiple service provider. The implementation of any FIM and SSOprotocol is complex due to the involvement of multiple organizations, sensitive user data, and myriadsecurity issues. There are many instances of faulty implementations that compromised on security forease of implementation due to lack of proper guidance. OpenID Connect (OIDC) is the latest protocolwhich is an open standard, lightweight and platform independent to implement Federated IdentityManagement; it offers several advantages over the legacy protocols and is expected to have widespreaduse. An implementation framework that addresses all the important aspects of the FIM lifecycle isrequired to ensure the proper application of the OIDC protocol at the enterprise level. In this researchwork, an implementation framework was designed for OIDC protocol by incorporating all the importantrequirements from a managerial, technical and security perspective of an enterprise level federatedidentity management. The research work closely follows the design science research process, and theframework was evaluated for its completeness, efficiency, and usability.

More and more companies are working toward digitizing their workflow and this has increased the necessity of digital signatures.An important part of digital signatures is the authentication process which is heavily regulated for Swedish government agencies by DIGG, DIGG only allows the use of Security Assertion Mark-up Language(SAML) for authentication but are looking into also allowing OpenID Connect(OIDC) and together with Swedish OIDC working group produce a specification.This thesis is looking into this preliminary specification and exploring if OIDC can do everything that SAML can do in regards of digital signatures, and if the inclusion of OIDC would render SAML obsolete.This is explored by implementing OIDC in twoday's services that follow DIGG's specifications to see if there are needs that OpenID Connect cannot meet.From the restriction in the thesis there was nothing that SAML could do that OIDC could not do, On the contrary their are features in OIDC that SAML could not match.The inclussion of OIDC would not make SAML obsolete unless customers use-cases evolve to include the features that SAML could not match.

Single Sign-On (SSO) är en autentiseringsprocess som tillåter en utvecklare att delegera autentiseringsansvaret till en dedikerad tjänst. OAuth 2.0 är ett auktoriseringsramverk som ofta står som grund för ett autentiseringslager som i sin tur möjliggör SSO. En identitetsleverantör är tjänsten som står för hantering av användaruppgifterna och autentiseringen, två vanliga identitetsleverantörer är Google och Facebook som i sin tur implementerar SSO med hjälp utav autentiseringslagren OpenID Connect respektive Facebooks egna autentiseringslager. Det har visat sig att många klienter som ska utnyttja SSO med OAuth 2.0 implementerar det fel så att säkerhetsbrister uppstår, studier har utförts med förslag till lösningar men många bristande implementationer fortsätter produceras och existera. Att skapa diverse verktyg för att främja säkerhet i dessa sammanhang är en metod där OAuthGuard utvecklats med visionen att även kunna skydda användaren, direkt från en webbläsare. OAuthGuard har även tidigare använts för att analysera säkerheten med Google SSO och visat att 50% av undersökta klienter har brister, men motsvarande studie eller verktyg saknas för Facebook SSO. Denna studie gjorde en motsvarande undersökning för Facebook SSO-klienter med en vidareutvecklad version av OAuthGuard och fann att de lider av brister med liknande trend som tidigare studies resultat mot Google-SSO-klienter, men att färre Facebook- SSO-klienter har brister i jämförelse. Vid vidareutvecklingen av OAuthGuard upptäcktes ett antal svårigheter och framtiden för denna typ av verktyg behöver vidare analyseras. Vidare analys behöver även göras för att bedöma om Facebook-SSO kan vara att föredra över Google-SSO ur säkerhetsperspektiv samt vidare utforskande av nya säkerhetsfrämjande metoder behöver utföras. / Single Sign-On (SSO) is an authentication process that allows a developer to delegate the authentication responsibility to a dedicated service. OAuth 2.0 is an authorization framework that often serves as a base for authentication layers to be built upon that in turn allows for SSO. An identity provider is the service that is responsible for handling user credentials and the authentication, two common identity providers are Google and Facebook that implement SSO with the authentication layers OpenID Connect respectively Facebooks own authentication layer. It has been shown that many clients using OAuth 2.0 as base for SSO make faulty implementations leading to security issues, a number of studies has proposed solutions to these issues but faulty implementations are continually being made. To create various tools to promote security in these contexts is a method where OAuthGuard has been developed with the vision to also directly protect the common website user directly from the browser. OAuthGuard has been used in an earlier study to analyze the security of clients using Google SSO and discovered that 50% of the analyzed clients had flaws, no comparable study has been done for clients using Facebook SSO, which is the second largest third party log in variant. This study made a comparable investigation for Facebook SSO clients with a further developed version of OAuthGuard and found that these clients suffer from flaws with a similar trend as the previous study with Google-SSO clients, although fewer Facebook-SSO clients suffer from these flaws. When further developing OAuthGuard a dumber of difficulties was discovered and the future of these kind of tools needs to be investigated. Further analysis needs to be done to assess if Facebook-SSO should be recommended over Google-SSO from a security perspective and also further exploration of new methods to promote security needs to be done.